This is the mail archive of the
mailing list for the glibc project.
Re: Second 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: Thu, 28 Jan 2016 21:13:55 +0000
- Subject: Re: Second draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160128204114 dot 6c7dbbf7 dot albert dot aribaud at 3adev dot fr>
I don't think the classification of whether symbols are "Y2038-sensitive"
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
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
Joseph S. Myers