On Tue, 2020-02-04 at 11:03 -0500, Lennart Sorensen wrote: > On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote: > > > * 32-bit ABIs/arches are more awkward. glibc will continue *by > > > default* to use 32-bit time_t to keep compatibility with existing > > > code. This will *not* be safe as we approach 2038. > > > > > > * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc > > > upwards, but this will of course affect the ABI. Embedded uses of > > > time_t in libraries will change size, etc. This *will* be safe for > > > 2038. > > > > And that's chosen at build time (i.e. when compiling glibc)? > > Why not provide different entry points for time-manipulating functions, > > so a single build can support both applications using 32bit time and > > applications using 64bit time?
If I recall correctly, glibc *will* provide both entry points, so there
is no ABI break. But the size of time_t (etc.) exposed through libc-
dev is fixed at glibc build time.
You should expect that all proposals have already been made and
discussed on the glibc-alpha mailing list over the past few years.
> > E.g.
> >
> > struct time32_t ...
> > struct time64_t ...
> >
> > double difftime32 (time32_t time1, time32_t time0);
> > double difftime64 (time64_t time1, time64_t time0);
> >
> > and in the time.h have
> >
> > #if TOO_OLD_TO_LIVE_PAST_2038
> > typedef time32_t time_t;
> > ...
> > #else
> > typedef time64_t time_t;
> > ...
> > #endif
>
> I agree. Why should this be any different than 64 bit file support?
> Transparent on 64 bit architectures, and 32bit code gets to pick the
> one it wants to support at compile time while glibc supports both,
> and eventually just about everything switches. You can even eventually
> add warnings when any program calls the 32 bit version of the functions.
LFS is a great example of how *not* to do it. 23 years on, we still
have open bugs for programs that should opt in but didn't. Not every
program needs to handle > 2 GiB files, but there are now filesystems
with 64-bit inode numbers and they break every non-LFS program that
calls stat().
Similarly, every program that uses wall-clock time will fail as we
approach 2038, and the failure mode is likely to be even worse than
with LFS as few programs will check for errors from time APIs.
Ben.
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
signature.asc
Description: This is a digitally signed message part
