public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/1190] New: fgetc()/fread() behaviour is not POSIX compliant
@ 2005-08-10 16:12 funtoos at yahoo dot com
  2005-08-10 16:15 ` [Bug libc/1190] " funtoos at yahoo dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 16+ messages in thread
From: funtoos at yahoo dot com @ 2005-08-10 16:12 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-09-23  5:25 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-1190-131@http.sourceware.org/bugzilla/>
2011-10-27  2:08 ` [Bug libc/1190] fgetc()/fread() behaviour is not POSIX compliant bugdal at aerifal dot cx
2011-10-27  2:08 ` bugdal at aerifal dot cx
2011-11-04 18:31 ` gotom at debian dot or.jp
2012-02-21  1:33 ` [Bug stdio/1190] " jsm28 at gcc dot gnu.org
2012-02-21  2:01 ` funtoos at yahoo dot com
2012-03-17 20:34 ` bugdal at aerifal dot cx
2012-03-18 14:23 ` jsm28 at gcc dot gnu.org
2012-09-13 13:33 ` siddhesh at redhat dot com
2012-09-13 13:52 ` siddhesh at redhat dot com
2012-09-13 14:15 ` siddhesh at redhat dot com
2022-09-23  5:25 ` fweimer at redhat dot com
2005-08-10 16:12 [Bug libc/1190] New: " funtoos at yahoo dot com
2005-08-10 16:15 ` [Bug libc/1190] " funtoos at yahoo dot com
2005-09-28  5:34 ` drepper at redhat dot com
2005-09-30 20:50 ` funtoos at yahoo dot com
2005-12-30 15:31 ` aj at suse dot de
2007-02-18  4:39 ` drepper at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).