Re: Accelerating Y2038 glibc fixes

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 18 Jul 2019, Adhemerval Zanella wrote:

> So what about to not add a user-selected way to set the time_t size
> (as off_t) and just enable time64_t support and sets is as default for 
> build with a minimum kernel of v5.1 (if I recall correctly as being the 
> one that added time64 support)? 

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.

Given that you have compatibility with existing binaries (as opposed to a 
complete new incompatible libc.so.7 ABI with building libc.so.6 for that 
architecture ceasing to be supported by glibc), eliminating support for 
building with _TIME_BITS=32 makes the changes much *harder*, not easier.  
There are three logical steps in the time_t transition.

(a) Support building applications for 64-bit time_t, using _TIME_BITS=64.

(b) Change the default to _TIME_BITS=64 (also requires defaulting to 
_FILE_OFFSET_BITS=64).

(c) Remove support for building applications with _TIME_BITS=32.

The hardest of those steps is (c), not (a), because of the difficulty in 
both building and testing all the compatibility symbols after step (c), 
without all the header redirections of symbols getting in the way when 
building those functions and the tests for them.

In view of the difficulty of both (c) and (a), it clearly makes sense to 
separate them, and start with (a), with (c) to follow some time later.

> I also wish we could also move forward with off_t and set LFS as default 
> as well.

We can (it's the equivalent of (c), not of (b), that's particularly hard, 
though even when doing (b) you need to be careful you keep sufficient test 
coverage for both function variants).  See what I said in 
<https://sourceware.org/ml/libc-alpha/2019-01/msg00124.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com