public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "funtoos at yahoo dot com" <sourceware-bugzilla@sources.redhat.com> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/1190] New: fgetc()/fread() behaviour is not POSIX compliant Date: Wed, 10 Aug 2005 16:12:00 -0000 [thread overview] Message-ID: <20050810161252.1190.funtoos@yahoo.com> (raw) 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.
next reply other threads:[~2005-08-10 16:12 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-08-10 16:12 funtoos at yahoo dot com [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050810161252.1190.funtoos@yahoo.com \ --to=sourceware-bugzilla@sources.redhat.com \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).