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. -- Len Sorensen
