Re: [PATCH 2/2] Y2038: make __tz_convert compatible with 64-bit-time

[Florian Weimer <fweimer at redhat dot com>]

On 06/13/2018 04:24 PM, Joseph Myers wrote:
> On Wed, 13 Jun 2018, Florian Weimer wrote:
>
> > > They're going to be implementations of APIs called from user source code
> > > if/when it defines _TIME_BITS equal to 64 (that'll be the last patch in
> > > the whole series), so I don't understand how they could be considered
> > > GLIBC_PRIVATE.
> >
> > Why do they use the __ prefix?  We generally do not do that.
>
> Because we want to fix bug 14106, and not replicate it for new interfaces
> (and don't intend to have explicit *64 APIs at all for 64-bit time_t, just
> new ABIs, on platforms where time_t is currently 32-bit, which can be
> selected using _TIME_BITS=64).

Ohh, right.

On the other hand, it is quite awkward why these obscure interfaces 
receive protection from accidental interposition, when others where we 
know that there is ongoing interposition (fadd, fdiv, canonicalize, 
explicit_bzero, getrandom, even getline) do not.

This relates to an older thread:

  <https://sourceware.org/ml/libc-alpha/2016-10/msg00294.html>

It also affects _GNU_SOURCE avoidance for libstdc++, depending on how we 
view this.  (Formal compliance vs avoiding collisions which occur in 
practice.)

Thanks,
Florian