Re: [Bug-gnulib] proposed patch for getpass and unlocked-io

[Bruno Haible]

Paul Eggert wrote:
> > I don't understand this. Larry Jones explained that the problem is inside
> > the stdio, not inside the kernel or tty driver, therefore the test
> > (out == in) is the right one.
>
> My worry here was about POSIX, not the C standard.  The C standard
> doesn't have fileno, so it need not worry about the case where out !=
> in && fileno (out) == fileno (in), a case that could happen here.
> ... Perhaps there's a solid argument as to why the out ==
> in optimization will work on all practical porting targets, but I
> don't know what it is offhand.

I think the fileno is irrelevant here: When you look at the Linux kernel
source (as an example for general POSIX systems), you see that lseek
does nothing on ttys (n_tty.c and tty_io.c). The only effect of the
fseek() call is therefore at libc level, fiddling with the FILE stream's
direction and buffer. Therefore it's irrelevant whether fileno (out) ==
fileno (in).

> I also considered removing the '#if
> !_LIBC' test around the fseek, but rejected that since I figure the
> code must be absent from glibc for a reason.

The reason is probably in the FILE structure of glibc.

> I just noticed another problem: the fseek is done only if buf != NULL
> && 0 <= nread && buf[nread - 1] == '\n'.  It should also be done if
> out == stderr, as otherwise if the program later outputs to stderr
> then the behavior will be undefined.

Yes, right, well spotted!

Bruno