On Tue, Feb 04, 2020 at 11:03:03AM -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? > > 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. In practice, despite LFS_CFLAGS having been a priority for Debian as far back as 2003, I think it was no more than 5 years ago that I was still finding libraries in the archive that were incompatible with LFS because they were leaking 32-bit types into their own ABIs. I think the lesson to be learned from 64-bit file support is that this was NOT managed effectively as a transition. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature