Re: Accelerating Y2038 glibc fixes

[Joseph Myers <joseph@codesourcery.com>]

On Mon, 29 Jul 2019, Adhemerval Zanella wrote:

> > I think duplicating ABIs like this is a very bad idea - the ABI supported 
> > by glibc for a configuration that currently has 32-bit time_t should not 
> > change to have two different, incompatible variants depending on how glibc 
> > is configured.  The default API provided by glibc should also not vary 
> > like that depending on how glibc is configured.
> 
> Later on the thread [1] I did state I would prefer switch based on release
> rather than a configure option, the suggestion was initially as a way to
> easier the transition (at the cost of complexity I give you).

I'm not clear what "switch based on release" means.

> Since we require to have both time32 and time64 implementation for the
> 'legacy' 32-bit architectures, the change to implement (c) is mainly to
> make the symbol compat ones.  And since we will need to internal logic

No, it's mainly (for a large number of functions) finding some way to 
avoid the unconditional (for platforms with __TIMESIZE == 32) header 
redirects from <func> to __<func>_time64 applying to the definitions of 
those compat symbols (and, likewise, for all the functions that have 
variants for _FILE_OFFSET_BITS=32, because we don't want to support the 
combination of 32-bit offsets with 64-bit times, and requiring 64-bit 
times implies first requiring 64-bit offsets).  You can do that with a 
suitable #define before including the header and #undef after, but there 
are many functions, and different implementations of those functions to 
deal with - and then there is the testing issue, where the changes are 
probably even more involved.

Just adding new function variants with new names and header redirection to 
provide optional support for using them is much simpler than anything that 
also obsoletes the old functions.

> The question I have is what is the real gain of still supporting _TIME_BITS=32
> as a build option, if the idea is default to _TIME_BITS=64.  It open a 

The gain is supporting building glibc itself for such configurations 
without a large amount of complicated work to build and test compat 
symbols needing to be done up front - allowing the transition to be broken 
down into more reasonably sized pieces.

-- 
Joseph S. Myers
joseph@codesourcery.com