This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define
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.
Building an application with 64-bit time_t using older headers is
likely to cause random problems.
Arnd