[PATCH] prevent retries on fclose/fflush after write errors

Mike Frysinger vapier at gentoo.org
Tue Mar 13 21:07:32 UTC 2012


On Tuesday 13 March 2012 16:56:13 u-uclibc-qs50 at aetey.se wrote:
> On Tue, Mar 13, 2012 at 04:24:33PM -0400, Mike Frysinger wrote:
> > > It should definitely not be added near the
> > > beginning of the structure, only past elements that could be part of
> > > the macro ABI.
> > 
> > that would help only if the uClibc code itself had versioned functions
> > which handled the growing struct.
> 
> Curious, why wouldn't this work without versioned functions?

if end user code encodes sizeof(FILE) anywhere, they're creating a memory 
region of a fixed number of bytes, so increasing the structure means that the 
app will give us a pointer to memory of X bytes, but the library requires it 
to be Y (where Y is greater than X) bytes, so the library will clobber memory 
the user did not intend.  declare "char buf[sizeof(FILE)]; FILE *x = buf;" on 
the stack and uClibc will overwrite random stuff on the stack.

> FILE structures are expected to be allocated by the library

your sub-thread here indicated that someone other than uClibc was allocating 
FILE structures (or i misread).  that cannot work w/out symbol versioning.

if uClibc is the only thing that allocates/uses these structures, then 
appending members should be fine.

> Of course this generally only works if the macros are not being changed.

correct, any existing members which are exposed via macros as part of the 
public API would have to remain in place.

> > if you're attempting to support code that
> > allocated sizeof(FILE) memory (which is dumb), then location in the
> > struct wouldn't matter.
> 
> I don't think keeping the size of FILE constant is practically important,
> even though I mentioned this as an incompatibility.

if by "practically" you mean we don't care about the end users who are relying 
on sizeof(FILE), then sure (i don't care about that use case).  i was just 
being pedantic in my reply.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120313/330dcc48/attachment.asc>


More information about the uClibc mailing list