[PATCH] prevent retries on fclose/fflush after write errors
dalias at aerifal.cx
Tue Mar 13 17:14:12 UTC 2012
On Tue, Mar 13, 2012 at 04:06:35PM +0000, u-uclibc-qs50 at aetey.se wrote:
> Hi Rich,
> On Tue, Mar 13, 2012 at 10:36:48AM -0400, Rich Felker wrote:
> > > > On Tue, Mar 13, 2012 at 01:41:01AM -0400, Mike Frysinger wrote:
> > > > > > int __filedes;
> > > > > > + int __errno_value;
> > > You are right Rich but it seems you are thinking of API while this change
> > > breaks ABI.
> > If it does, I still don't see how it could. Applications cannot
> > declare objects of type FILE, only FILE *. Short of some macros that
> > poke at the early members of the structure (getc/putc macros), it's
> Applications actually can declare, allocate, copy FILE objects
> unless explicitely prohibited by the specification - does it
> prohibit this? All I found is a mention that a copy of a FILE object
> is unusable at a different address than the original
> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 266
> last paragraph).
Applications presumably can do this, but the only use for doing so
would be to use the object as a buffer of type `char[sizeof(FILE)]`.
It can't be used for any purpose connected with stdio. And being that
the size is very arbitrary, I can't see how you could use it for
anything useful; the only thing you know about `sizeof(FILE)` is that
it's greater than or equal to 1. Presumably it could even have size
SIZE_MAX to prevent applications from declaring objects of type
> That's why I assume that the FILE structure as a whole is a part of the
> ABI, despite being opaque.
> I may be wrong reading/interpreting specification(s), then please
> correct me.
> The actual change being discussed may be compatible in practice,
> I take your word for this!
I believe you may be technically correct, but there's no correct/sane
program that would be affected by this ABI change.
More information about the uClibc