This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5] y2038: Introduce __ASSUME_TIME64_SYSCALLS define
On Sat, 25 May 2019, Stepan Golosunov wrote:
> In most cases code can look like this:
>
> #ifdef __ASSUME_TIME64_SYSCALLS
> #ifndef __NR_clock_settime64
> #define __NR_clock_settime64 __NR_clock_settime
> #endif
> INLINE_SYSCALL_CALL (clock_settime64, …)
> #else
> try clock_settime64, if that fails (whether compiletime or runtime)
> convert data to 32-bit, call clock_settime
> #endif
>
> (Yes, for semtimedop it won't be that simple. Because traditional
> syscall isn't semtimedop in some cases. This also assumes that the
If we follow this approach, it would be reasonable to say that
__ASSUME_TIME64_SYSCALLS is *only* for those syscalls where the old
syscall, on platforms that had 64-bit time in their syscall interface all
along, is exactly equivalent (and to list that subset) - not for
semtimedop. Then there could be a separate __ASSUME_SEMTIMEDOP_TIME64.
> 20 time64 syscall names won't suddenly be added to kernel headers for
> 64-bit ABIs.)
Rather, that they won't be added *with new syscall numbers*. If the
kernel adds them as macro aliases for the old syscall numbers, code like
that would work just fine. If the kernel adds them as new syscall
numbers, the definition of __ASSUME_TIME64_SYSCALLS (that assumes it can
always be true for existing 64-bit syscall ABIs) would suddenly become
wrong when using new kernel headers, because it would result in glibc code
using new syscall numbers without regard to a possibly older runtime
kernel version.
--
Joseph S. Myers
joseph@codesourcery.com