Re: [PATCH] Y2038: provide kernel support indication

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 25 Sep 2018, Joseph Myers wrote:

> Yes, subject to the question of what's appropriate on 64-bit architectures 
> where time_t always has been 64-bit and the existing names of syscalls, 
> not the new ones, are used for all time-related syscalls.  If 
> __ASSUME_KERNEL_Y2038_SUPPORT means the syscalls with the new names are 
> guaranteed to be present, then it should be undefined in that case because 
> only the old names will be present (but also the variable etc. relating to 
> runtime tests for support should not be declared at all, so if any code 
> with such tests is - wrongly - compiled on such an architecture, it will 
> fail to compile).

There is of course also a possible variant for 64-bit architectures if it 
proves better for the implementation:

* Make a glibc-internal header #define all the __NR_* for the new syscall 
names to point to the old names if the kernel headers don't do so.

* Define __ASSUME_KERNEL_Y2038_SUPPORT unconditionally for such 
architectures, because the syscalls in question are in fact old ones so 
always present at runtime.  (If the kernel headers might define the new 
__NR_* names *and point them to new syscall numbers*, it's more 
complicated, because in that case it would no longer be correct to assume 
the syscalls are available with an old kernel, but it would be completely 
useless to have runtime checks to decide between using old and new syscall 
numbers for the same syscall.  Also, if there are new syscalls that e.g. 
use timespec where existing ones use timeval and so are genuinely new even 
on 64-bit architectures, you'd end up needing to split 
__ASSUME_KERNEL_Y2038_SUPPORT into separate macros for the separate groups 
of syscalls.)

-- 
Joseph S. Myers
joseph@codesourcery.com