This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Y2038: make __tz_convert compatible with 64-bit-time
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