On Tuesday 13 March 2012 15:32:01 Rich Felker wrote: > On Tue, Mar 13, 2012 at 07:19:35PM +0000, u-uclibc-q...@aetey.se wrote: > > > there's no correct/sane > > > program that would be affected by this ABI change. > > > > Actually I suspect that stdio macros might use stuff (like __bufpos) > > which is located past the proposed new structure member, in which case > > existing binaries would become incompatible with a patched library: > > > > >>> #endif /* __UCLIBC_HAS_WCHAR__ */ > > >>> int __filedes; > > >>> + int __errno_value; > > >>> #ifdef __STDIO_BUFFERS > > >>> unsigned char *__bufstart; /* pointer to buffer */ > > >>> unsigned char *__bufend; /* pointer to 1 past end of > > >>> buffer */ > > > > -> unsigned char *__bufpos; > > Indeed, I missed this. 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. if you're attempting to support code that allocated sizeof(FILE) memory (which is dumb), then location in the struct wouldn't matter. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
