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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 3 May 2018 19:30:56 +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>
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