Re: Fourth draft of the Y2038 design document

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 22 Jun 2016, Arnd Bergmann wrote:

> We can avoid most of the problems if building with _TIME_BITS=64
> has no effect unless both glibc and the kernel headers are new
> enough to provide the definitions for 64-bit time_t. That way
> we can at least ensure that calling an ioctl command or setsockopt
> with an incompatible ABI will result in an error code rather than
> wrong data.

I'd be a lot more comfortable with requiring new kernel headers to build 
and use glibc than with requiring a new kernel at runtime for 
_TIME_BITS=64 to work.  New kernel headers are one of the easiest things 
to use when building glibc, since we have the --with-headers option.  (In 
fact right now the headers requirement (3.2) is newer than the runtime 
requirement (2.6.32) on x86_64 / x86.)

(_TIME_BITS=64 should of course be an OS-independent API, supported for 
all glibc configurations.  Obviously exactly what Hurd does is up to the 
Hurd maintainers, as probably is fixing Hurd to keep it working with 
_TIME_BITS=64, but _TIME_BITS=64 should clearly enable 64-bit time_t for 
it even if some underlying Y2038-safety is missing.  NaCl already has 
64-bit time_t so _TIME_BITS=64 would have no effect there.)

-- 
Joseph S. Myers
joseph@codesourcery.com