[PATCH 1/1] stdio: fix named pipe issue

[Jian Peng]

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-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf Of Rich Felker
Sent: Thursday, June 16, 2011 4:11 PM
To: uclibc at 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 at uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc