[PATCH] prevent retries on fclose/fflush after write errors
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc