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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH 1/1] stdio: fix named pipe issue
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: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rich Felker Sent: Thursday, June 16, 2011 3:39 PM To: uclibc@uclibc.org 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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/1] stdio: fix named pipe issue
Jian, Rich, All, On Friday 17 June 2011 01:04:44 Jian Peng wrote: 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. I would suggest that this be /protected/ by a config option, that the user can set in the menuconfig. I am not saying that the patch is correct or wrong, nor am I saying that it should be applied or dumped. I'm only suggesting that this compatibility stuff might have more chance to get in if it is protected by a config option. We already have a few compatibility knobs, so either we add that new compatibility stuff to an existing knob, or we add a new one. I for one believe standards have a role to play, so we should stick to them as much as possible; OTOH, usability is a must, and if people expect a certain behavior that diverges from the standard because it is been done as such in the most widely deployed systems, then offering those users that care the option to enable that compatibility stuff is good, but we should also cover the case for those users that want to abide by the standards. My 2 eurocents. ;-) Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/1] stdio: fix named pipe issue
On Thu, Jun 16, 2011 at 04:04:44PM -0700, Jian Peng wrote: 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. Certainly these broken apps will also fail on other OS's, perhaps BSD's or commercial unices. Wouldn't it be better to just fix them? It's probably a one-line patch, adding clearerr() after the EOF is encountered. By the way, I don't think glibc special-cases fifos like this. Rather, it merely ignores the rule that read functions are supposed to fail if the EOF flag for the stream is set, and thus retries reading. For normal files this gives the same results as the standard requires, but for fifos and such, it can be different. I believe this behavior difference is documented somewhere in the various writings about the differences between glibc and uClibc (and glibc intentional/WONTFIX bugs), so somebody will probably be unhappy if you go breaking uClibc like this - especially if you do it the bloated expensive way rather than just having read functions ignore the EOF flag. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH 1/1] stdio: fix named pipe issue
Fully agree. -Original Message- From: Yann E. MORIN [mailto:yann.morin.1...@anciens.enib.fr] Sent: Thursday, June 16, 2011 4:18 PM To: uclibc@uclibc.org Cc: Jian Peng; Rich Felker Subject: Re: [PATCH 1/1] stdio: fix named pipe issue Jian, Rich, All, On Friday 17 June 2011 01:04:44 Jian Peng wrote: 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. I would suggest that this be /protected/ by a config option, that the user can set in the menuconfig. I am not saying that the patch is correct or wrong, nor am I saying that it should be applied or dumped. I'm only suggesting that this compatibility stuff might have more chance to get in if it is protected by a config option. We already have a few compatibility knobs, so either we add that new compatibility stuff to an existing knob, or we add a new one. I for one believe standards have a role to play, so we should stick to them as much as possible; OTOH, usability is a must, and if people expect a certain behavior that diverges from the standard because it is been done as such in the most widely deployed systems, then offering those users that care the option to enable that compatibility stuff is good, but we should also cover the case for those users that want to abide by the standards. My 2 eurocents. ;-) Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH 1/1] stdio: fix named pipe issue
I really like to see this kind of glibc to uClibc migration guide that has enough detail to cover similar problems. If I saw it before, I will not spend my time on this problem by then. Very unfortunately, this documents did not exist, at least not searchable. This seems a really big missing piece in www.uclibc.org -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rich Felker Sent: Thursday, June 16, 2011 4:11 PM To: uclibc@uclibc.org Subject: Re: [PATCH 1/1] stdio: fix named pipe issue On Thu, Jun 16, 2011 at 04:04:44PM -0700, Jian Peng wrote: 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. Certainly these broken apps will also fail on other OS's, perhaps BSD's or commercial unices. Wouldn't it be better to just fix them? It's probably a one-line patch, adding clearerr() after the EOF is encountered. By the way, I don't think glibc special-cases fifos like this. Rather, it merely ignores the rule that read functions are supposed to fail if the EOF flag for the stream is set, and thus retries reading. For normal files this gives the same results as the standard requires, but for fifos and such, it can be different. I believe this behavior difference is documented somewhere in the various writings about the differences between glibc and uClibc (and glibc intentional/WONTFIX bugs), so somebody will probably be unhappy if you go breaking uClibc like this - especially if you do it the bloated expensive way rather than just having read functions ignore the EOF flag. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/1] stdio: fix named pipe issue
On 06/16/2011 04:28 PM, Jian Peng wrote: I really like to see this kind of glibc to uClibc migration guide that has enough detail to cover similar problems. there is a starter where this should be documented as well. doc/Glibc_vs_uClibc_Differences.txt thats all. Thanks -Khem ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
