This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Second draft of the Y2038 design document

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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]