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: Joseph Myers <joseph at codesourcery dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 22 Feb 2017 16:59:21 +0000
- Subject: Re: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr>
I don't think the description of how APIs are mapped to 64-bit versions is
right.
You say "New 32-bit symbols would be named after their corresponding
32-bit symbol plus "64", e.g. the 64-bit implementation of clock_gettime
would be named clock_gettime64.". But actually, as per a following point,
the ABI symbol should be named __clock_gettime64, in the implementation
namespace. And there shouldn't be a public API called clock_gettime64 at
all (hopefully), the way to use the 64-bit versions should be
-D_TIME_BITS=64 (and then calling clock_gettime).
You refer to "#define clock_gettime clock_gettime64". But #define is only
used for remapping in the case of non-__GNUC__ compilers without an
implementation of __REDIRECT, a case that probably hasn't worked with
glibc's headers for years. The remapping should be done with __REDIRECT,
and such #define only if __REDIRECT is not defined.
Similarly there might be an internal __time64_t, but not a public type by
the time64_t name. And remapping struct tags is only possible with
#define, which may be problematic, not with typedef, and can't be done at
all for existing tags because of effects on C++ name mangling; struct
timespec should probably have tag timespec in any case, with its contents
differing depending on _TIME_BITS (just like struct stat has contents
depending on _FILE_OFFSET_BITS).
--
Joseph S. Myers
joseph@codesourcery.com