This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Second draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Joseph Myers <joseph at codesourcery dot com>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Date: Fri, 29 Jan 2016 00:30:11 +0100
- 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> <alpine dot DEB dot 2 dot 10 dot 1601282059200 dot 6102 at digraph dot polyomino dot org dot uk>
On Thursday 28 January 2016 21:13:55 Joseph Myers wrote:
> 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.
The only example I can think of that is limited in this way is utimes
and kstat operating on file systems that cannot store time stamps beyond
2038, e.g. ext3. Setting a timestamp to a later date on such a file system
currently has undefined behavior (wraparound in some way) and we are
in the process of changing the kernel so it can instead either clamp
the values to the minimum/maximum representable times, or return an
error (the exact policy is not decided yet, but it should become
deterministic).
> 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.
Right, this is not architecture specific, just a couple of bugs in kernel
interfaces that are currently limited to 32-bit times internally. This
includes mostly file systems, but also some device drivers and network
protocols. In many cases, the internal (network, hardware, firmware, ...)
representation is an unsigned 32-bit number, so the overflow will not
happen until 2106.
Arnd