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: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Tue, 12 Jun 2018 00:24:06 +0200
- 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> <1a4c2101-130f-79bd-71ff-3393c42c000e@redhat.com> <ccf24625-05e8-85ec-9767-31e90e20c7d0@cs.ucla.edu> <20180503193056.0ded171f@athena> <6f29bd3f-6d2f-f6d6-4efd-a46f2b1cf5fa@cs.ucla.edu> <20180522225805.695d3175@athena> <0c2702d2-fe4b-125f-7dc4-c649aa6747d8@cs.ucla.edu> <alpine.DEB.2.20.1805222206000.29227@digraph.polyomino.org.uk>
Hi Joseph,
On Tue, 22 May 2018 22:09:55 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Tue, 22 May 2018, Paul Eggert wrote:
>
> > As I recall, there were other unnecessary duplications in the proposed set of
> > patches, so this is not just an issue of difftime.
>
> Indeed. The global approach should be: the main implementation of any
> functionality that involves nontrivial implementation code in glibc is the
> one that uses 64-bit time, unconditionally, on all platforms. On
> platforms that currently have 32-bit time_t, the public interfaces for
> 32-bit times would become thin wrappers round those for 64-bit times while
> new public ABIs are added for 64-bit times (on platforms that currently
> have 64-bit time_t, there would be no new ABIs). If kernel support for
> 64-bit times is not known to be available for the (architecture, kernel
> version) pair for which glibc is built, the implementations in terms of
> 64-bit times may then need to translate back to 32-bit times, with
> overflow checks, to call into the kernel.
When a 64-bit time implementation needs to translate back to 32-bit
times before calling to the kernel, would it not be counter-productive
to make the 32-bit interface a wrapper around it? This would hit the
32-bit client code with two conversions (from the 32-bit interface
to the 64-bit implementation, and from the implementation to the 32-
bit kernel syscall) when the original 32-bit interface would make none
and call the kernel (as) directly (as possible).
Cordialement,
Albert ARIBAUD
3ADEV