This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define


On Tue, Aug 27, 2019 at 07:35:14PM +0000, Joseph Myers wrote:
> On Tue, 27 Aug 2019, Zack Weinberg wrote:
> 
> > I think that gets everything important.  Neither the commit message
> > nor the comment needs to list all the new system calls.
> 
> The syscalls need to be listed to make clear exactly what the interfaces 
> covered by the macro are.
> 
> * If further related syscalls are added in future, e.g. timespec64 
> versions of syscalls that currently use struct rusage, they are *not* 
> covered by this macro.
> 
> * If the semantics of the unsuffixed syscall on 64-bit architectures do 
> not exactly match those of the suffixed syscall on 32-bit architectures, 
> so that a #define of the suffixed name to the unsuffixed name doesn't 
> suffice to use the existing syscall on 64-bit architectures, it is *not* 
> covered by this macro, at least not without an explanation of the semantic 
> differences in the comment.  (See the semtimedop discussion.)

To clarify, none of the timespec ones "exactly match" -- the suffixed
syscalls on 32-bit require filling the padding around tv_nsec, whereas
the unsuffixed 64-bit ones don't (because there is no padding since
long is 64-bit). This does not affect using the unsuffixed 64-bit
syscall in place of the suffixed syscall (which AIUI is the usage you
had in mind), but would affect the reverse substitution. Any updates
to wording around this should try to avoid making the matter more
confusing to readers, IMO.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]