[[PATCH RFC 2] 02/63] Y2038: add function __difftime64

[Albert ARIBAUD]

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