Re: Fifth draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

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