This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Accelerating Y2038 glibc fixes
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