From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82689 invoked by alias); 3 May 2018 17:31:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 82674 invoked by uid 89); 3 May 2018 17:31:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=albert, devoid, gladly, aiming X-HELO: smtp3-g21.free.fr Date: Thu, 03 May 2018 17:31:00 -0000 From: Albert ARIBAUD To: Paul Eggert Cc: Florian Weimer , libc-alpha@sourceware.org Subject: Re: [[PATCH RFC 2] 02/63] Y2038: add function __difftime64 Message-ID: <20180503193056.0ded171f@athena> In-Reply-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00073.txt.bz2 Hi Paul, On Wed, 2 May 2018 12:07:32 -0700, Paul Eggert 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