Re: [musl] Re: time64 abi choices for glibc and musl

[Rich Felker <dalias at libc dot org>]

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