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

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Paul,

On Thu, 19 Apr 2018 14:36:20 -0700, Paul Eggert <eggert@cs.ucla.edu>
wrote :

> On 04/19/2018 06:04 AM, Albert ARIBAUD wrote:
> > One reason to have a separated implementation is that difftime.c has
> > quite complex logic covering many different implementations of time_t
> > (signed, unsigned, with padding bits) whereas here we only have signed
> > 64-bit integer.  
> 
> difftime.c is a general implementation that works regardless of the 
> widths of time_t, int, long, etc. You tried reinventing its wheel but 
> the reinvention was buggy. Although you could try reinventing its wheel 
> again, I am afraid there will be another bug with reasonably high 
> probability. Instead, let's reuse the wheel that we already have; that 
> will be more likely to be correct, and will be easier to maintain in the 
> future.

I'd argue that the wheel we already have was built for the roads we
intended it to run on, but this change might be the occasion to update
to a wheel which will only run on a subset of roads where some of the
current wheel's properties become unneeded.

IOW: does the set of 32-bit architectures on which we will use
64-bit with 32-bit time need all the complexities of current difftime?
I'm thinking for instance about padding bits.

> It's not just difftime.c. The same argument applies to mktime, etc. We 
> shouldn't have two copies of these functions' source code: we should 
> have just one generic copy, and then compile it once for 64-bit 
> __time64_t and once for 32-bit time_t. The generic code already works 
> for both 64-bit and 32-bit time_t, so it should also work for 64-bit 
> __time64_t.

OK, so let me rephrase this to see if I am getting this :

1) Keep the original file untouched as the 32-bit-time compilation unit.
Compiling this file as it is now ensures that the ABI is untouched.

2) Compile the same original file with -D_TIME_BITS=64 (just like
application code would be compiled under 64-bit-time), producing a
second compilation unit which provides new symbols.

The problem with this approach is that it can be applied to some
implementations but that for many, the 64-bit version is *not*
functionally identical with the 32-bit one. 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.

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, which is contrary to one of the goals of Y2038; existing
GLIBC 32-bit time code should be unchanged.

I can respin the changes so that I apply your proposal for cases
where no syscalls are involved [1].

(Note: some time-related implementations are for protocols and file
formats. These will probably require extra care because we need to make
sure the protocol and file structures are actually independent on the
size of time_t.)

> At bottom I am repeating the comment that Joseph Myers made here:
> 
> https://sourceware.org/ml/libc-alpha/2018-04/msg00376.html

Cordialement,
Albert ARIBAUD
3ADEV