[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] proposed patch for getpass and unlocked-io
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] proposed patch for getpass and unlocked-io |
Date: |
Thu, 9 Oct 2003 12:34:31 +0200 |
User-agent: |
KMail/1.5 |
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