This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>
- Date: Tue, 27 Aug 2019 19:35:14 +0000
- Subject: Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- Ironport-sdr: QZTwvpTv3N2CLxUO+/kMB+UVmmEcIz/r/GeD/GNteMrlnkGIKwe9P1yUrrGzSmBm6GrB0t6h0I /P9mDMceH2vdGIBnFdTruo9PM8ezRiPwY8SXdOhsb141Lz+qSK4nESMWKWwBc8/UkJOS70PzxN e4J1EsqdZrqXJJ+IJ5REWbDa5f/sPl8wqD9OUhi9mLhdi3x4V71SNGZmNcsR4/ossI/nMwK0dm Wh4/FYfGwvHpDxja97gIfWEvEydPrYpdqX4GRyWWxboJDehdqxY+or+MnlIWm9xz8IsW/6VBWb DiE=
- Ironport-sdr: Z9mtTVcz9inUXC7wlr46cKRVTpx1l04DsUgBBWAQIu85eTKWjXvBDBMLjU8QOZur9Flz3O4o33 xQpvvpJ4r9mFS9ZAY/aFDgTcqKkEXSXgIW4woNz3b359HJEOxu56XdTs6x8EA+KSKlsICzD9SU U2SHVOv7T16iUIFIzi9o5LRHOdEXR1/QFbH1J2xfKd3ttJIk9+0s72cO5WNSDkFBDXqFbldHVb CQZUYtFbV7TpkM6ArYun32OkkfSw7vcNXgC9QBQQsKMq3mUfaAWvJwZxfPNSGPqn02jIVTltG8 NOQ=
- References: <20190827173015.24370-1-alistair.francis@wdc.com> <CAKCAbMiYinyQ_Gdcu94rPCm6PNw6hdq+H_dhzeADa89v2z13-A@mail.gmail.com>
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.)
* If the unsuffixed syscall is not in fact available on all 64-bit
architectures supported by glibc in the minimum supported kernel version,
it is *not* covered by this macro. (Although treating it as covered would
only cause issues if there is actually any fallback code for the case
where the unsuffixed syscall isn't present either.)
The fact that the syscalls described by the macro may be suffixed or
unsuffixed also needs to be in the comment, not just the commit message.
--
Joseph S. Myers
joseph@codesourcery.com