This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Accelerating Y2038 glibc fixes
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Lukasz Majewski <lukma at denx dot de>, Wolfgang Denk <wd at denx dot de>, GNU C Library <libc-alpha at sourceware dot org>, Alistair Francis <alistair dot francis at wdc dot com>, Alistair Francis <alistair23 at gmail dot com>
- Date: Tue, 30 Jul 2019 19:58:25 +0000
- Subject: Re: Accelerating Y2038 glibc fixes
- References: <20190712072103.D3DBC24003A@gemini.denx.de> <alpine.DEB.2.21.1907251934270.17883@digraph.polyomino.org.uk> <20190726123902.6f8813da@jawa> <CAKCAbMjvrgebp9qhbK3TiH3fNEx+Xg0B9tGgJv=iVjRwUKEdoQ@mail.gmail.com>
On Mon, 29 Jul 2019, Zack Weinberg wrote:
> Q5: Is it correct that __ASSUME_TIME64_SYSCALLS is only defined
> when the new constants are guaranteed to be defined?
Either the new constants, *or* constants such as __NR_clock_settime if
those syscalls use 64-bit time with the same semantics as the suffixed
syscalls.
Note that if Florian's changes to include syscall lists in glibc go in
then we could assume the constants for the new syscalls are defined in all
cases where the old syscalls don't use 64-bit time. That might slightly
simplify some of the code, by eliminating the case "__TIMESIZE == 32,
constants for syscalls with 64-bit time are not defined".
--
Joseph S. Myers
joseph@codesourcery.com