Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 1 Jun 2019, Stepan Golosunov wrote:

> > I see how splitting semtimedop/semtimedop_time64
> > availability from __ASSUME_DIRECT_SYSVIPC_SYSCALLS can help to
> > untangle __ASSUME_DIRECT_SYSVIPC_SYSCALLS from time64.  (It would
> > probably be overkill though—in the end splitted macro would be defined
> > exactly at the same time as __ASSUME_DIRECT_SYSVIPC_SYSCALLS.)
> > 
> > I fail to see how not using __ASSUME_TIME64_SYSCALLS can add anything
> > but extra complexity into the following logic:

The basic rule, for each syscall covered by __ASSUME_TIME64_SYSCALLS, if 
we use the semantics that __ASSUME_TIME64_SYSCALLS is defined 
unconditionally for existing 64-bit syscall ABIs, is that the following is 
always OK:

#ifdef __ASSUME_TIME64_SYSCALLS
# ifndef __NR_foo_time64
#  define __NR_foo_time64 __NR_foo
# endif
/* Implementation that uses foo_time64 unconditionally.  */
#else
/* Implementation that needs fallback code.  */
#endif

My understanding is that this would not work for semtimedop, because not 
all 64-bit syscall ABIs have __NR_semtimedop.  (Or, equivalently, it would 
work for semtimedop *only* if the syscall ABIs in question avoided 
defining __ASSUME_TIME64_SYSCALLS before Linux 5.1 - but since those ABIs 
do have the other syscalls, that wouldn't be helpful.)

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.

Note: I haven't verified if all 64-bit syscall ABIs did have all the other 
syscalls in the list as of Linux 3.2, or if any other cases should also be 
split out.

-- 
Joseph S. Myers
joseph@codesourcery.com