[PATCH] prevent retries on fclose/fflush after write errors
dalias at aerifal.cx
Tue Mar 13 22:38:43 UTC 2012
On Tue, Mar 13, 2012 at 05:07:32PM -0400, Mike Frysinger wrote:
> 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.
Passing this FILE * to stdio functions invokes undefined behavior.
They all require a FILE * obtained from fopen/fdopen/popen/etc. or
from one of the standard stream pointers (stdin/stdout/stderr). The C
standard is very explicit that you are not allowed to use copies of
FILEs, and without copying an existing one, there's no way to
construct one that would be valid anyway.
> > 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.
No one but uClibc can allocate them.
More information about the uClibc