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

[Florian Weimer]

On 06/13/2018 12:20 PM, Albert ARIBAUD wrote:
> Hi Florian,
> 
> On Wed, 13 Jun 2018 11:40:04 +0200, Florian Weimer <fweimer@redhat.com>
> wrote :
> 
>> On 06/13/2018 11:36 AM, Albert ARIBAUD wrote:
>>> Hi Florian,
>>>
>>> On Wed, 13 Jun 2018 11:10:09 +0200, Florian Weimer <fweimer@redhat.com>
>>> wrote :
>>>    
>>>> On 06/13/2018 09:00 AM, Albert ARIBAUD (3ADEV) wrote:
>>   [...]
>>>>
>>>> Functions in the private namespace should be exported as GLIBC_PRIVATE.
>>>> Except __gmtime64_r, these functions have unwanted side effects and
>>>> cannot really be called from other parts of glibc anyway.
>>>
>>> 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.
> 
> I believe it stemmed from the fact that source code should not spell
> these functions by their explicit name -- that name is to be used by
> glibc only. User source code should keep using the historical names
> (here, "gmtime_r"); if it has defined _TIME_BITS equal to 64, then the
> glibc public headers will alias (or barring that, #define) gmtime_r to
> __gmtime64_r (the 64-bit-time implementation); otherwise, "gmtime_r"
> will be used as-is (the 32-bit-time implementation).
> 
> So to make sure the symbols were considered to not be for (direct)
> public use, they have to start with an underscore.

We use non-__ names for the LFS redirects (slightly trimmed):

# ifdef __REDIRECT
extern FILE *__REDIRECT (fopen, (const char *__restrict,
                                  const char *__restrict), fopen64);
extern FILE *__REDIRECT (freopen, (const char *__restrict,
                                    const char *__restrict,
                                    FILE *__restrict), freopen64);
# else
#  define fopen fopen64
#  define freopen freopen64
# endif
#endif

I don't see a totally conforming way to implement this using redirects 
anyway, so whether __ is used or not is secondary because it doesn't 
address the main problem.

>>> As for the side effects, which ones are you thinking of? The ones I am
>>> aware of are those already present in the 32-bit-time versions and are
>>> "regrettable but established behavior".
>>
>> The side effects simply mean that we cannot call this functions as an
>> internal implementation detail of another function, so there should be
>> no reason for an export in the private namespace (with the __prefix and
>> GLIBC_PRIVATE).
> 
> Actually another function can call these functions -- the 32-bit-time
> wrappers do that exactly. I must be missing your point.

Yes, but that those are libc-only and they won't need the exports.  A 
hidden alias with a __ name would be sufficient under such circumstances.

Thanks,
Florian