Re: Second draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 29 Jan 2016, Arnd Bergmann wrote:

> 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 main point here is that there is no glibc issue - glibc just passes 
64-bit time_t values to / from the kernel and it's the kernel's job to 
handle things appropriately if there are limitations from e.g. 
filesystems.

-- 
Joseph S. Myers
joseph@codesourcery.com