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

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

Hi Paul,

On Wed, 2 May 2018 12:07:32 -0700, Paul Eggert <eggert@cs.ucla.edu>
wrote :

> On 05/02/2018 12:46 AM, Florian Weimer wrote:
> >
> > Yes, you can simplify the code if you want, assuming that time_t 
> > doesn't have padding bits, and even hard-code the matching unsigned type.  
> 
> The simplified code is already in difftime.c. All he needs to do is to 
> compile difftime.c with the right flags, and perhaps make some trivial 
> changes to it that won't affect its current use.

Actually, the simpler code in difftime.c which 64-bit signed integer
needs is enclosed in run-time conditionals, not compile-time
conditionals, so there are no flags that can make the code compile to a
simpler form. It just does a lot of run-time tests (*) which only some
architectures or some time_t implementations actually need.

> I'd be more impressed by his request to rewrite the code from scratch if 
> his attempt to do so hadn't been so buggy. Really, we'll all be better 
> off using the code we already have, as that code should work in this new 
> environment with only trivial changes, and we can then focus on what our 
> main problem is rather than have to delve back into the intricacies of 
> time_t arithmetic and calendars and whatnot.

I would love that too, and one way of not delving into intricacies is
to remove them if this can be done safely in a given context. I will
gladly admit I might have removed slightly too much of the difftime
intricacies in 64-bit signed time context, and I do believe in the
"don't fix it if it ain't broken" approach, but I'm not aiming to fix
32-bit time here with all its implementations, integer or floating,
signed or unsigned, padded or not; I'm aiming to make 64-bit, integer,
unpadded time as devoid of undue intricacies as it can be.

(*) Which might possibly, but not will not necessarily, be optimized
away by some compilers based on the target architecture's time_t type
and/or signedness and/or size, or even on known architecture quirks --
I am choosing not to assume how clever compilers can be, and I consider
that putting a run-time test in some source code will be costlier in
execution time than not putting it there.

Cordialement,
Albert ARIBAUD
3ADEV