Accelerating Y2038 glibc fixes
Joseph Myers
joseph@codesourcery.com
Thu Jul 25 20:40:00 GMT 2019
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
More information about the Libc-alpha
mailing list