Unfortunately, glibc is the most widely used C library and de facto testing environment used by most application developers. I am not familiar with C standard, but every standard had evolved to meet the requirement of its end users, so to this point, glibc implemented in the way that satisfied its end users.
In case that uClibc was used as a replacement of glibc, this kind of subtle discrepancy just hinder this migration. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rich Felker Sent: Thursday, June 16, 2011 3:39 PM To: [email protected] Subject: Re: [PATCH 1/1] stdio: fix named pipe issue On Thu, Jun 16, 2011 at 11:54:45AM -0700, Jian Peng wrote: > This is follow-up of my investigation and proposed > fix at > http://old.nabble.com/named-pipe-is-borken-and-proposed-fix-td31753483.html#a31753483 > > The testing programs worked well with glibc, but failed in uClibc-0.9.32. > > As Laurent pointed out, this is undefined in standard. For the sake of > application developers who want to port apps from glibc to uClibc without > worrying about the subtle difference, it is nice to help them out with > following patch. > > The problem is that FIFO is a special file type, and the conventional EOF > is useless, and should not be set. > > The fix is to avoid setting __FLAG_EOF for stream associated with FIFO file > after all senders were closed. This patch adds bloat and as far as I can tell it's wrong. The standard (C) says that the EOF indicator is set when EOF is reached, that it is not cleared until you call clearerr or fseek/rewind, and that fgetc returns EOF if the EOF indicator is set. If glibc does not behave this way for fifos, that's a glibc bug. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
