Re: Accelerating Y2038 glibc fixes

[Joseph Myers <joseph@codesourcery.com>]

On Mon, 29 Jul 2019, Adhemerval Zanella wrote:

> I think it would be easier than what you described because we won't need
> to actually to add any header redefinition, all symbol affect will just
> use the new time_t regardless of the ABI.  The compat implementation will
> use an internal-only type to use the old one.
> 
> What it would require is to add compat implementations with a different
> type, time32_t for instance.  Something like:

That seems much harder to implement through incremental development, 
whereas with _TIME_BITS=64 things can readily be implemented incrementally 
(adding 64-bit functions one-by-one with 32-bit ones as wrappers - already 
done for various mktime / timezone functions, for example - with only the 
final addition of _TIME_BITS=64 support in the headers and exporting 
symbols at public symbol versions needing to be one big monolithic patch).

> I don't have a strong opinion if a patch proposal use the _TIME_BITS=32
> as a initial transition to enable time64 support, however I see no point
> in make it available either on a release point neither in long term. 

The point is _TIME_BITS=64 as an API, not _TIME_BITS=32.  Since the change 
to flip the default is small, I don't think it's very significant whether 
or not there is a release where the default is 64-bit but _TIME_BITS=32 is 
available as well (whereas having _TIME_BITS=64 available before it 
becomes the default is a practical matter of both reviewability and 
allowing users to plan the timing of their own transition to 64-bit 
times).

-- 
Joseph S. Myers
joseph@codesourcery.com