[PATCH v5] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Stepan Golosunov]

15.05.2019 ц≈ 16:27:23 +0200 Lukasz Majewski ц▌ц│ц░ц┴ц⌠ц│ц▄:
> This define indicates if the Linux kernel (5.1+) provides syscalls supporting
> 64 bit versions of struct timespec and timeval.
> 
> For architectures with __WORDSIZE==64 and __TIMESIZE==64 (e.g. x86_64, aarch64)
> this flag is never defined (as those already use 64 bit versions of struct
> timespec and timeval).
> 
> The __ASSUME_TIME64_SYSCALLS shall be only defined on systems with
> __WORDSIZE==32.
> 
> For x32 this flag is explicitly undefined as this architecture has
> __WORDSIZE==32 with __TIMESIZE==64. Despite having __WORDSIZE==32 the x32
> has support for 64 bit time values and hence needs to undefine
> __ASSUME_TIME64_SYSCALLS flag.

What is not clear is how architectures where syscalls like
clock_settime are already using 64-bit time_t are supposed to be
identified.  Last patch for clock_settime seems to be using

#if __WORDSIZE != 32 || !defined __NR_clock_settime64 && defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64

to select code for these architectures.

This seems too complicated and potentially buggy.  Why not just
define __ASSUME_TIME64_SYSCALLS for this case too and then use

#if defined __ASSUME_TIME64_SYSCALLS && !defined __NR_clock_settime64

?

Especially given that in most cases the only difference in resulting
code with __ASSUME_TIME64_SYSCALLS defined would be the name of the
constant used (__NR_clock_settime64 when it's defined,
__NR_clock_settime otherwise).