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

[Rich Felker <dalias@libc.org>]

On Sun, Aug 11, 2019 at 09:55:14PM -0400, Rich Felker wrote:
> On Sun, Aug 11, 2019 at 05:31:48PM -0700, Paul Eggert wrote:
> > Rich Felker wrote:
> > >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.
> > 
> > It doesn't entirely simplify libc, as it enlarges struct stat and
> > (more importantly) makes struct stat tricky. This is a judgment
> > call, but I would say we're better off in the long run with a
> > simpler struct stat that ordinary programmers will understand
> > easily, even if this complicates nftw implementation during the
> > transition.
> 
> The various archs already have random junk padding in struct stat.

Apologies; I was under a longstanding mistaken impression that glibc
used the kernel stat64 types, and had per-arch bits headers to provide
them, but apparently it doesn't and always uses its own fixed, fairly
clean layout (sadly without reserved space for expansion), though.

So indeed it would be a little bit of an uglification to add
time64-on-32-bit-arch members here. I still think the benefits to
minimizing breakage of applications (and avoiding the need for
duplicate [n]ftw implementations and symbol redirects, which nobody
has proposed doing yet, likely because nobody even realized they would
have been needed) are worth it, but my assessment was wrong.

This also means whatever glibc decides to do about struct stat is
irrelevant to musl's glibc-ABI-compat goals; what I assumed was
working now is in fact broken, but doesn't matter because the __xstat
shims can fix it up if desired.

Rich