On Tuesday 13 March 2012 16:56:13 u-uclibc-q...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
