Re: Fwd: Fifth draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 2 Mar 2017, Zack Weinberg wrote:

> > There's no such configure option.  glibc version N provides support for
> > _TIME_BITS=64 where previous versions do not.
> 
> ... Why do you insist that there is no such configure option?  Version
> N provides _TIME_BITS=64 support *if* --enable-64-bit-time-t is used,
> and that requires the presence of a newer kernel at runtime.  (Should
> make a point of bombing out early in ld.so initialization.)

I think having twice as many ABI variants of libc.so etc. is obviously a 
bad idea.  Programs built for glibc version N should work with glibc 
shared libraries from a different build of glibc version N for the same 
architecture etc., rather than adding this extra variable.

> Yes, lots of ifdefs, but I reiterate that I am not convinced any
> alternative is even _possible_.  To fall back to clock_gettime (the
> system call) at runtime, when clock_gettime64 (again, the system call)
> fails with ENOSYS, would require copying arguments.  That's not a
> problem for clock_gettime, but it *is* potentially a problem for
> ioctl, sendmsg, etc.  Witness the sendmsg-socklen_t-vs-size_t patches
> that had to be scrapped.

I don't expect glibc to copy for sendmsg or ioctl; there, I expect that 
(given new enough kernel headers) _TIME_BITS=64 would result in different 
constants being passed to the syscalls which then might fail in the 
absence of kernel support.

I do expect all the interfaces listed on the wiki page as explicitly 
involving timestamps as being able to work with _TIME_BITS=64 on an old 
kernel.

I do expect the functions that use times internally but not in their 
interface to be able to be changed to use 64-bit-time interfaces 
unconditionally, and for this to work on an old kernel.  (Whether this is 
needed for calls to e.g. __xstat64 if times aren't actually used from the 
resulting structure would depend on what __xstat64 does with too-large 
timestamps; if the kernel saturates them, a change may not strictly be 
needed, but if EOVERFLOW errors occur then a change would be needed.  And 
given the desire to support kernels with 32-bit-time syscalls disabled, a 
change to such calls is probably desirable in any case.)

-- 
Joseph S. Myers
joseph@codesourcery.com