> Hi Dmitry,
> let me try to explain my point and please correct me if I'm
> When I saw this patch for the first time, I realized that
> batch_readline_init() may be called with tty, socket, unnamed
> pipe or whatever that has no name on filesystem. Calling fstat()
> on something that has no associated file name looks suspicious,
> but I don't know for sure if it is permitted or not.
All of these entities (unnamed pipe, socket etc.) have an associated file descriptor.
fstat can be called for any object that have associated file descriptor and it doesn't
matter have that a name in file system or not.
So, I don't see any problem at all.
> That's why I asked:
> What if I run "mysql > abc", or in other words what if
> input_fd is a tty?
If input file descriptor refers to opened tty then when mysqld starts and opens stdin it
gets access to this terminal for input. If such terminal associtated with your input
then all that you will be typing will be accessible as input to mysqld.
> and later asked:
> What if I run my_fstat() on unnamed fd (e.g. tty, socket, unnamed
You can call fstat on any object that have a file descriptor. Any of next objects - tty,
socket, unnamed pipe has a file descriptor
so I don't see any problem at all.
> But there is no answer whatsoever. Ok.
> Later I realized that this is probably a regression caused by
> fix for BUG#41486. As far as I can see fill_buffer() returns
> -1 on error and 0 on eof. But with fix for BUG#41486
> intern_read_line() ignores error from fill_buffer(), unless
> buffer->eof is set.
> So the main question is: what benefit gives hidding a bug in
> intern_read_line() instead of restoring original logics?
First, I didn't know about bug 41486 when I was implementing my patch.
Second, when I was inspecting this source code I found a bug in handling of
error from read syscall. I fixed this error. I don't consider that I should redesign this
piece of source code. If redesign is needed
then a separate request for redesign should be created.