This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [[PATCH RFC 2] 02/63] Y2038: add function __difftime64
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 2 May 2018 12:14:07 -0700
- Subject: Re: [[PATCH RFC 2] 02/63] Y2038: add function __difftime64
- References: <20180418201819.15952-1-albert.aribaud@3adev.fr> <20180418201819.15952-2-albert.aribaud@3adev.fr> <20180418201819.15952-3-albert.aribaud@3adev.fr> <0a04fc43-9e92-1bbc-843d-049d1026d971@cs.ucla.edu> <20180419150411.4d7ee629@athena> <34e2461c-5da4-181d-d34b-b63c7f89dbf6@cs.ucla.edu> <20180502092209.540847ad@athena>
On 05/02/2018 12:22 AM, Albert ARIBAUD wrote:
At least the
syscall-dependent ones work differently: the 32-bit impelmentations
just use the 32-bit syscalls, while the 64-bit implementations have to
use the 64-bit syscalls *if availaible at run-time*, and be able to
fallback on the 32-bit syscalls if they have to.
That's fine, and we can have code protected by ifdef to do that as
needed for the special case where the system has multiple time_t flavors
some of which might not work. This doesn't mean we need to have separate
copies of the entire module that needs to use such code.
And for functions like difftime that do not use time_t-related syscalls,
things should be even simpler, as we shouldn't need to worry about this
issue in those functions.
Using a single source code for both 32-bit time and 64-bit time
would mean that 32-bit syscall-based implementation behavior would
change,
I don't see why it would, at least not if things were done as suggested
above.