[PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define

[Stepan Golosunov]

16.05.2019 ц≈ 06:00:56 +0200 Arnd Bergmann ц▌ц│ц░ц┴ц⌠ц│ц▄:
> On Wed, May 8, 2019 at 9:48 PM Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
> > 08.05.2019 ц≈ 09:51:23 +0200 Lukasz Majewski ц▌ц│ц░ц┴ц⌠ц│ц▄:
> 
> > You need to handle the following 4 cases:
> >
> > 1.  32-bit syscall should not be called (and may not even exist):
> > 1.1.  __NR_clock_settime is 64 bit.
> > 1.2.  __NR_clock_settime64 works in all supported kernels.
> >
> > 2.  __NR_clock_settime is 32-bit and __NR_clock_settime64 may be
> > unavailable.
> > 2.1.  __NR_clock_settime64 is available in kernel headers, but may
> > fail with ENOSYS when called.  32-bit __NR_clock_settime should be
> > called if __NR_clock_settime64 is failing.
> > 2.2.  __NR_clock_settime64 is not present in kernel headers.
> > 32-bit __NR_clock_settime should be called.
> 
> Is there still a chance to revisit that last case? I had assumed that
> glibc would have to require new kernel headers to support 64-bit
> time_t since some of the macro definitions (ioctl commands,
> socket options, ...) in the kernel have changed to deal with both
> cases.

This is about building glibc itself, not applications that use it.
And time_t would be 32-bit in this case anyway.

> Building an application with 64-bit time_t using older headers is
> likely to cause random problems.

Then it might be a good idea to check for recent enough kernel headers
when building programs that define _TIME_BITS to 64.  (Though if those
programs use above-mentioned ioctls and socket options they will
likely need new enough kernel at runtime too.)