Re: Second draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

I don't think the classification of whether symbols are "Y2038-sensitive" 
is useful.

The relevant question is: does the ABI to a function involve time_t, 
whether directory or indirectly (e.g. through struct stat)?  If it does, a 
separate version is needed for _TIME_BITS=64.  That includes functions 
involving relative timestamps.  And the notes "3. Regardless of the time_t 
size, the function may not return a time_t value beyond Y2038." and "4. 
Regardless of the time_t size, the function may not accept an time_t input 
value beyond Y2038." simply seem wrong - functions should accept, and be 
able to return, arbitrary valid time_t values.

There should (preferably) not be functions such as time64 that you 
mention, nor types such as time64_t, at the user API level.  Rather, 
_TIME_BITS=64 would cause time_t to be remapped to __time64_t and calls to 
time to end up calling __time64 at the assembler level.

I don't see how EDOM could be correct for out-of-range values.  EOVERFLOW 
seems clearly correct for overflow on both input and output.

The sentence "Symbol versioning appears unnecessary so far." is either 
wrong or meaningless, and so should be removed.  All new symbols get the 
appropriate symbol version for the first glibc release they are in.  It 
may well be the case that all new interfaces have new names at the 
assembler level - including e.g. __xstat64_time64 - rather than being new 
versions of existing names - but if that's what you mean, then say so (and 
explicitly address what the __xstat etc. interfaces would look like).

There is the matter of time interfaces used internally in glibc.  Just as 
glibc uses the stat64 interfaces internally (instead of defining 
_FILE_OFFSET_BITS=64 when glibc is built, because the redirections that 
implies would be problematic for building the 32-bit function variants), 
so I suppose glibc would internally use e.g. __clock_gettime_time64 when 
it needs to get a timestamp (and all glibc-internal uses of affected 
functions, including stat functions, would need reviewing to convert them 
to the new forms).  (When building for a 64-bit architecture, such calls 
would then need to be remapped back to the functions that actually exist 
in glibc.)

The claim "On some architectures, time_t is already 64-bit wide even 
though it still contains a signed value ranging from -2**31 to (2**31)-1. 
Introducing 64-bit support should only change the range from -2**63 to 
(2**63)-1." seems misleading.  On 64-bit platforms, there is no existing 
constraint that time_t contains a 32-bit value, and nothing for 64-bit 
support to fix in that regard; values may be arbitrary 64-bit values 
already.

-- 
Joseph S. Myers
joseph@codesourcery.com