[Bug libc/1190] New: fgetc()/fread() behaviour is not POSIX compliant

[Bug libc/1190] New: fgetc()/fread() behaviour is not POSIX compliant

[funtoos at yahoo dot com]

A simple setup consisting of two programs. process A writes to fpA pointing to
file /a/b/c and process B reads from fpB pointing to file /a/b/c. Process B does
a select on fileno(fpB) for read readiness and does a fread() for 200 bytes.
This leads to 256 bytes read and EOF. Process A writes more data to fpA. Process
B again does a select(), followed by the fread(). (The select() calls don't wait
for timeout=250 msecs that they are supposed to wait because eof is still set
and select() rightly assumes that the fd is ready for read.) The second fread()
succeeds when the data actually becomes available as written by process A. The
second fread() should fail as per POSIX standard because the eof is still not
cleared by the app and an fgetc() (used by fread()), returns eof if eof is set
on the stream. This leads bad coding practices in linux and non-portable
programs. The above is a live example of how non-portable the NX free client
(called nxrun) became when app developer assumed that he could keep reading
without resetting the eof on the stream. Not only the program hangs on solaris,
but it sits in a tight loop because select() returns immediately on eof and the
wait of 250 ms is rendered redundant, on both linux and solaris. If fgetc() and
hence fread() had refused to read if stream has eof set like they are supposed
as per POSIX, the programmer would have caught his mistake on linux and not led
to hang on solaris and tight loop on linux.

Please refer the following for correct POSIX behaviour of fgetc()/fread():

http://www.opengroup.org/onlinepubs/009695399/functions/fgetc.html
http://www.opengroup.org/onlinepubs/009695399/functions/fread.html

-- 
           Summary: fgetc()/fread() behaviour is not POSIX compliant
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: critical
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: funtoos at yahoo dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[funtoos at yahoo dot com]

------- Additional Comments From funtoos at yahoo dot com  2005-08-10 16:15 -------
sorry for 200/256 mess up. It should read 'process B does an fread() for 2000
bytes'. Also, processA wrote 256 bytes to begin the protocol.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-28 05:34 -------
I'm not going to spend a second on this until I see a small, self-contained
testcase.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[funtoos at yahoo dot com]

------- Additional Comments From funtoos at yahoo dot com  2005-09-30 20:50 -------
its a simple thing. fgetc() needs to return EOF if EOF is what the last call had
returned and is set on the stream, even though there is new data ready to be
read. EOF should be explicitly cleared (by the programmer) before the next call
to fgetc() is made by the programmer. This is a simple POSIX compliance
requirement as per the links I provided. What do we need a test case for? Are
you saying that the behaviour reported in the example is not the current
behaviour of glibc?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[aj at suse dot de]

------- Additional Comments From aj at suse dot de  2005-12-30 15:31 -------
Please send a self-contained test program that shows the bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-18 04:39 -------
No test program provided in more than a year.  Closing.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=1190

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[gotom at debian dot or.jp]

http://sourceware.org/bugzilla/show_bug.cgi?id=1190

GOTO Masanori <gotom at debian dot or.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gotom at debian dot or.jp
         AssignedTo|gotom at debian dot or.jp   |drepper.fsp at gmail dot
                   |                            |com

--- Comment #8 from GOTO Masanori <gotom at debian dot or.jp> 2011-11-04 18:31:35 UTC ---
It looks like "end-of-file" condition is cleared when gets() called (which
should be preserved according to the standard), like:

#include <stdio.h>
int main(void) {
  char buf[100];
  gets(buf);  // We need to type ^D
  gets(buf);  // We need to type ^D but the stream already received ^D
(end-of-file condition)
}

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=1190

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2011-10-27 02:08:30 UTC ---
Created attachment 6036
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6036
Tiny test-case showing the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=1190

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|WORKSFORME                  |

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2011-10-27 02:07:43 UTC ---
This bug still exists; I'm reopening it and adding a new attachment that
demonstrates it trivially. Actually I wrote this test-case a while back as a
demonstration of one of the very few safe uses of gets(), which happened to
become unsafe due to the bug in glibc.

To see the bug, run the program (stdio_eof.c) and press ^D (or whatever your
EOF key on the terminal is). The program should exit, but under glibc, the
gets() call waits for a line of input and prints it back before exiting.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.