This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 8 Mar 2017 13:27:32 +0100
- Subject: Re: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702221647560.8704@digraph.polyomino.org.uk> <20170222194855.7581deca.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702222055440.24643@digraph.polyomino.org.uk> <20170223131634.06fa476c.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702231418320.15395@digraph.polyomino.org.uk> <20170223165052.1b494e3a.albert.aribaud@3adev.fr>
Hi Albert,
On Thu, 23 Feb 2017 16:50:52 +0100, Albert ARIBAUD
<albert.aribaud@3adev.fr> wrote :
> Hi Joseph,
>
> On Thu, 23 Feb 2017 14:21:22 +0000, Joseph Myers
> <joseph@codesourcery.com> wrote :
>
> > On Thu, 23 Feb 2017, Albert ARIBAUD wrote:
> >
> > > - a [32-bit-time] implementation of 'int clock_gettime(clockid_t,
> > > struct timespec *tp)' exists, and is referred to by the implementation
> > > symbol '__clock_gettime'.
> > >
> > > - 'clock_gettime' redirects to '__clock_gettime'.
> >
> > No, it doesn't redirect. User application code is compiled to .o files
> > that reference clock_gettime, not __clock_gettime. __clock_gettime is a
> > GLIBC_PRIVATE symbol, only for internal use by glibc libraries when
> > required for namespace reasons, not for application code. Whereas
> > __clock_gettime64 would have a public GLIBC_2.X symbol version since
> > references to it would be generated by redirections in headers when the
> > user defines a feature test macro supported for user code.
>
> Thanks for the rectification; I think now I have the terminology and
> concepts straight, and -- assuming the rest is correct -- I will edit
> the document for next review.
Actually I still have a question there.
Assume one single source file (say, app.c) which includes <time.h> and
refers to 'clock_gettime'. This source code is compiled into two object
modules, one with -DTIME_BITS=64 (sayn app64.o) and one without (say,
app32.o). Both object modules expect to be linked and run against the
(same) GLIBC dynamic library. For the app32.o module, we expect its
call to 'clock_gettime' to end up executing '__clock_gettime' while for
the app64.o module, we expect its 'clock_gettime' call to end up
executing '__clock_gettime64'.
My question is, how exactly can the GLIBC API make app32.o use
'__clock_gettime' and app64.o use '__clock_gettime64' when app.c refers
to 'clock_gettime'?
I've though of defining, in time/time.h, clock_gettime as an alias of
either __clock_gettime or __clock_gettime64 depending on whether
__USE_TIME_BITS64 is defined or not, but you cannot use aliases in a
header file; you have to declare the alias in the same module where
the function body is also defined.
So, barring #define'ing the clock_gettime symbol, how can we get the
above done?
Cordialement,
Albert ARIBAUD
3ADEV