Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 4 Jun 2019, Stepan Golosunov wrote:

> > Splitting semtimedop out of what the comment on __ASSUME_TIME64_SYSCALLS 
> > says its semantics are seems cleaner to me than having more complicated 
> > semantics that are different as regards semtimedop than as regards all the 
> > other syscalls.  You can then have __ASSUME_SEMTIMEDOP_TIME64 with a 
> > comment explaining exactly what the semantics of that macro are for 64-bit 
> > syscall ABIs without a semtimedop syscall.
> 
> Do you mean that __ASSUME_SEMTIMEDOP_TIME64 should be separate from
> __ASSUME_TIME64_SYSCALLS so that they can have different wordings
> explaining the same "fallback to syscalls with 32-bit time_t is not
> needed" semantics?

It might well have a different definition as well, depending on what 
semantics make the most sense for it.

It's entirely OK to define some __ASSUME_* macros in terms of other 
__ASSUME_* macros, if that helps make the different cases and their 
relations clearer.  (E.g. look at the sets of macros we used to have 
relating to accept4, recvmmsg, sendmmsg, to deal with cases where they 
might sometimes be available with socketcall but not with a syscall, until 
the minimum kernel version became recent enough that we could always 
assume the functionality, if not a syscall for it, to be available, and so 
could simplify the code.)

__ASSUME_TIME64_SYSCALLS should have the simplest, clearest semantics that 
work for its purpose.  If any syscall needs something slightly different, 
it's appropriate to separate it out.  That includes if the previous 
versions of any of the other syscalls listed for __ASSUME_TIME64_SYSCALLS 
were not in fact present in 3.2 for all architectures supported by glibc 
(something I haven't checked, but which needs to be checked) - if any 
syscall has that as a complication, take it out of the list to which 
__ASSUME_TIME64_SYSCALLS applies and deal with that complication 
separately, later.

-- 
Joseph S. Myers
joseph@codesourcery.com