Re: Accelerating Y2038 glibc fixes

[Joseph Myers <joseph@codesourcery.com>]

On Mon, 29 Jul 2019, Paul Eggert wrote:

> On 7/29/19 4:08 PM, Joseph Myers wrote:
> > > 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
> 
> I worry that this puts the incremental cart before the incremental horse, at
> least for portable applications. If we take the _TIME_BITS=64 approach,
> portable applications should add the equivalent of "#define _TIME_BITS 64" to
> their config.h files or ihatever, because they should be Y2038-safe. But if
> glibc development is incremental so that some time_t uses are glitchy when
> _TIME_BITS=64, these applications will have problems. Conversely, if glibc
> doesn't publicize the time_t changes until they're ready (which I think is the
> intent), the _TIME_BITS=32 approach would be less hassle overall for portable
> applications; they won't have to change their source code.

Header support for _TIME_BITS=64 shouldn't be added until all functions 
fully support it.  At that point, having it not be the default for some 
number of releases helps users plan the ABI transition for their libraries 
(rather than getting an ABI break by default for any library that gets 
rebuilt with newer glibc unless a special option is used, they can plan a 
whole-distribution transition on their own timescale).

-- 
Joseph S. Myers
joseph@codesourcery.com