Date: Sat, 10 Aug 2019 22:18:18 -0400 From: Rich Felker <dalias@...c.org> To: Paul Eggert <eggert@...ucla.edu> Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com Subject: Re: Re: time64 abi choices for glibc and musl On Sat, Aug 10, 2019 at 01:15:34PM -0700, Paul Eggert wrote: > Rich Felker wrote: > >For struct stat, I think it's almost necessary to preserve the > >existing layout and add new time64 members on the end, and to continue > >filling in the time32 members. > > This won't be reliable for applications that call 'stat', fiddle > with the timestamps in the resulting 'struct stat', and then pass > the fiddled-with struct to some other function. If they fiddle with > the 64-bit timestamp the 32-bit copy will become wrong, and vice > versa. > > There are similar issues for applications that create struct stat > values by hand, without calling a 'stat'-like function. Changing any of the types defined by libc obviously alters the ABI between any two consumers of these types that uses the changed types as part of the interface between them. The only thing we can *guarantee* works is the interface between libc and a single consumer of libc. Since there's no function in libc which reads from a stat structure provided by the application, your concern seems to apply only to the case that's inherently a best-effort thing. Still, here it is useful to make a best effort, since the only typical way stat structures are passed around is share (unmodified) results obtained by performing one of the stat functions on a file. The [n]ftw matter, by itself, is something entirely different, and pertains to use of libc by a single consumer. Internally, [n]ftw performs stat on files and passes the result to a callback provided by the application. If the stat structure is not such that it can be accepted by either time32 or time64 callers, then [n]ftw need to be redirected symbols and there need to be two copies of the implementation, one that calls the old time32 stat and one that calls the time64 stat. This is a gratuitous pain on the implementation side. Now the two are actually related in some sense, because this same idiom, of passing stat results back to a caller, is fairly common in library code outside libc that does directory listings, tree walks, etc. The same condition that makes it [n]ftw painless on the libc implementation side also makes it so that this kind of library works with time32 callers when the library was built for time64 (assuming there are no other points of breakage). Again, this is a best-effort thing anyway, and can't inherently be expected to work, but the choice that makes things easy on the libc implementation side is *also* the choice that makes this work best. Thereby I consider it the most reasonable choice. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.