On Tue, Mar 13, 2012 at 04:06:35PM +0000, u-uclibc-q...@aetey.se wrote: > Hi Rich, > > On Tue, Mar 13, 2012 at 10:36:48AM -0400, Rich Felker wrote: > > > > On Tue, Mar 13, 2012 at 01:41:01AM -0400, Mike Frysinger wrote: > > > > > > int __filedes; > > > > > > + int __errno_value; > > > > You are right Rich but it seems you are thinking of API while this change > > > breaks ABI. > > > > If it does, I still don't see how it could. Applications cannot > > declare objects of type FILE, only FILE *. Short of some macros that > > poke at the early members of the structure (getc/putc macros), it's > > Applications actually can declare, allocate, copy FILE objects > unless explicitely prohibited by the specification - does it > prohibit this? All I found is a mention that a copy of a FILE object > is unusable at a different address than the original > (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 266 > last paragraph).
Applications presumably can do this, but the only use for doing so would be to use the object as a buffer of type `char[sizeof(FILE)]`. It can't be used for any purpose connected with stdio. And being that the size is very arbitrary, I can't see how you could use it for anything useful; the only thing you know about `sizeof(FILE)` is that it's greater than or equal to 1. Presumably it could even have size SIZE_MAX to prevent applications from declaring objects of type FILE... :-) > That's why I assume that the FILE structure as a whole is a part of the > ABI, despite being opaque. > > I may be wrong reading/interpreting specification(s), then please > correct me. > > The actual change being discussed may be compatible in practice, > I take your word for this! I believe you may be technically correct, but there's no correct/sane program that would be affected by this ABI change. Rich _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc