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
Hi Joseph,
On Wed, 22 Feb 2017 20:56:41 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Wed, 22 Feb 2017, Albert ARIBAUD wrote:
>
> > So the existing (32-bit time) public API symbol 'clock_gettime' has to
> > remain for 32-bit time callers, and another one needs to be provided
> > for 64-bit time callers -- that is the one which would be named
> > 'clock_gettime64'.
>
> But the API symbol for 64-bit callers is clock_gettime; such callers use
> _TIME_BITS=64. There should be no API clock_gettime64 at all, without a
> clear usage case for calling such a function from code built with
> _TIME_BITS=32.
I wasn't using "API symbol" the right way. Let me try to clear
this up, stop me when I'm wrong.
Currently,
- 'time_t' is an API symbol
- The implementation of 'time_t' is '__time_t'.
- 'struct timespec' is an API symbol.
- 'clock_gettime', 'time_t', 'struct timespec' are API symbols.
- 'int clock_gettime(clockid_t, struct timespec *tp)' is an API.
- 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'.
Adding 64-bit time then consists in the following changes to the above:
- The implementation of 'time_t' is either '__time_t' or '__time64_t'
depending on _TIME_BITS.
- a [64-bit-time] implementation of 'int clock_gettime(clockid_t,
struct timespec *tp)' exists in addition to the 32-bit one,
and is referred to by the implementation symbol '__clock_gettime64'.
- 'clock_gettime' redirects to either '__clock_gettime' or
'__clock_gettime64' depending on _TIME_BITS.
Is this correct?
Once I'm sure I get it right, I'll go through the document and make sure
I use the right symbols.
Cordialement,
Albert ARIBAUD
3ADEV