Re: BZ #1190: stream behaviour on encountering an EOF

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

Yikes, sorry. The bugzilla should be 1190. Changed the subject line
accordingly.

Regards,
Siddhesh

On Thu, 13 Sep 2012 19:40:11 +0530, Siddhesh wrote:

> Hi,
> 
> The aforementioned bz describes an incompatibility of glibc with posix
> when it comes to behaviour of fread, fgets, etc. The POSIX standard
> implies that if an end-of-file is encountered in a stream, subsequent
> calls on that stream will continue to return EOF until the stream
> state is changed with fseek or similar. The behaviour we have however
> is different and the reason for this seems to be to maintain
> compatibility with SysV, as mentioned in fileops.c:
> 
> ...
> int
> _IO_new_file_underflow (fp)
>      _IO_FILE *fp;
> {
>   _IO_ssize_t count;
> #if 0
>   /* SysV does not make this test; take it out for compatibility */
>   if (fp->_flags & _IO_EOF_SEEN)
>     return (EOF);
> #endif
> 
> ...
> 
> glibc behaviour is to do a sys_read if there's nothing on the buffer.
> It is inconsequential for actual files that have not changed, since
> the read would return a 0 again, but it results in blocking on stdin
> and I imagine, on pipes as well.
> 
> Should we really be fixing this at all? A lot of applications could be
> depending on this behaviour and fixing this to comply with POSIX would
> imply breaking all those programs.
> 
> The fix itself is quite simple - uncomment the above and place some
> more similar checks in other places where a read doesn't go through
> the underflow mechanism.
> 
> Regards,
> Siddhesh