Re: Accelerating Y2038 glibc fixes

[Paul Eggert <eggert@cs.ucla.edu>]

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.