[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190812015514.GO9017@brightrain.aerifal.cx>
Date: Sun, 11 Aug 2019 21:55:14 -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 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.
It's true that the time64 transition would allow the 32-bit archs to
do away with this and invent a uniform definition that they can all
share, but the 64-bit archs would still be stuck with all the legacy
stuff, and struct stat still needs to be an arch-specific bits header
anyway. I don't see much value in making things "prettier" for 32-bit
here when we can't do the same for 64-bit, especially when the vast
majority of users are 64-bit.
The reason I mention "random junk padding" is that, in the long term,
that's what the time32 members end up becoming. If building with
_TIME_BITS=32 is no longer supported at some point, they don't even
have to be called __st_atim32 or whatever anymore; they can be called
__reservedN or whatever, and effectively they're just like the other
padding junk in struct stat. If at some point in the distant, distant
future time32 binaries are no longer supported at all, these reserved
members could even be repurposed for something else if needed.
Aside from time_t and struct timespec themselves, which *have to*
change in an incompatible way, struct stat is probably the most widely
used time_t-dependent data type defined by libc. As stated before,
making things work when time32 and time64 code get linked in the same
program is inherently a best-effort thing at best, but struct stat is
one case where making a best effort will usually be sufficient not to
have any breakage (and only non-serious, invalid-read breakage if
breakage happens).
Both glibc and musl place significant value on stable ABI and
compatibility with users' binaries and libraries. For glibc, every
gratuitous breakage when time32 and time64 code gets mixed is going to
make users hesitant to define _TIME_BITS=64, and thereby delay the
eventual switchover of the default. The switchover very well might get
delayed well past "too late" already, leaving broken stuff all over
the place with 2038 quickly approaching.
For musl, there is not going to be a build option unless you roll your
own by building with old headers. After the time64 release, all newly
built programs will be using time64. As such, distros are going to
have to deal with any breakage that occurs right away, and users
who've built stuff themselves are going to end up dealing with
mismatches. As part of being responsible about our promises of stable
ABI, I do not want to be introducing gratuitous breakage where it
could easily have been avoided. The other types mentioned in my
original email are fairly inconsequential (not going to appear in
interfaces between libraries), but stat is important and does appear.
For what it's worth, as long as glibc is doing the __xstat thing, we
can provide ABI-compat shims through that and not really care if the
layout matches. But I really think glibc would be better off not
breaking things here, so that the transition is as painless as
possible.
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.
