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

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

On Wed, 2 May 2018 09:22:09 +0200, Albert ARIBAUD
<albert.aribaud@3adev.fr> wrote :

> 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.

more to the point, it would be compiled *as if* under -D_TIME_BITS=64,
because TIME_BITS and __USE_TIME_BITS64 are public API macros which
are not defined at GLIBC build time -- and a git grep shows that no
GLIBC '.c' file ever references a __USE_* or _*_BITS macro defined in
features.h.

> 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.

Also, 64-bit time types are not simply 32-bit time types with time_t
promoted to 64-bit signed, so there too, simply compiling the source
code would not always work.

Cordialement,
Albert ARIBAUD
3ADEV