From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100179 invoked by alias); 25 Jun 2018 22:32:57 -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 99704 invoked by uid 89); 25 Jun 2018 22:32:56 -0000 Authentication-Results: sourceware.org; auth=none 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=H*r:212.27.42, albert, Albert, cordialement X-HELO: smtp1-g21.free.fr Date: Mon, 25 Jun 2018 22:32:00 -0000 From: Albert ARIBAUD To: Paul Eggert Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 1/1] Y2038: add function __difftime64 Message-ID: <20180626003245.023eb716@athena> In-Reply-To: <31f71b4a-6141-f27a-3385-3653f58adb28@cs.ucla.edu> References: <20180620121427.25397-1-albert.aribaud@3adev.fr> <20180620121427.25397-2-albert.aribaud@3adev.fr> <9b02ad78-15cf-969e-b2ef-cae13d5a689e@cs.ucla.edu> <20180620225545.4eb76291@athena> <31f71b4a-6141-f27a-3385-3653f58adb28@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00768.txt.bz2 Hi Paul, On Thu, 21 Jun 2018 14:17:24 -0700, Paul Eggert wrote : > On 06/20/2018 01:55 PM, Albert ARIBAUD wrote: > > > [...] > >> Since no glibc code calls difftime, can we assume that a later patch > >> will change will make __difftime64 and difftime both available to user > >> code? I'm not getting the big picture here. > > Actually, this is not an assumption > > In that case, I'm still puzzled about the specific example of difftime. > Are you assuming that glibc can export just one difftime function to > 32-bit user code, and that because every 32-bit time_t value fits into > __time64_t this single function will work with both time_t and > __time64_t? That assumption fails in many platforms (as they use > different calling conventions for 32-bit versus 64-bit integers), so in > general a glibc implementation on a platform that currently has 32-bit > time_t will need to export two difftime entry points. I am indeed assuming that every 32-bit time_t value will fit into a 64-bit __time64_t, but I don't infer from this that 64-bit as well as 32-bit time user code could use a single function as their difftime. Actually, if you'll remember my first rounds of RFC patches (which you did comment), I had initially elected to provide a 64-bit difftime alongside the original difftime; and later, since wrappers seemed to be the preference, I replaced the original 32-bit difftime with a wrapper around the 64-bit time; and in both cases, there were two functions, on for each time size. > > What actually happened is, I am getting quite more feedback now than I > > got with the RFCs. > > That's a good sign. You're getting feedback now. Many patches languish > nearly forever because nobody has the time to review them, unfortunately. > > > I'll provide two branches for reviewers > > Thanks, please let us know when they're ready. That will help me answer > questions like the difftime question above. > > > We do currently have unsigned 32-bit time_t implementations, but do we > > have unsigned 64-bit time_t? A signed 64-bit integer __time64_t was > > a core assumption > > That can be a core assumption of glibc, but for code shared with Gnulib > we'd rather not make assumptions like that. It's little trouble to > support unsigned 64-bit (or even wider) time_t in Gnulib code, and we > should continue to support this. All we should need to assume is that > every time_t value fits into __time64_t. Come to think of it, __time64_t > will be a misnomer in Gnulib since __time64_t is not necessarily a > 64-bit type, so perhaps code shared with Gnulib should continue to use > the name "internal_time_t" (for internal use only, of course) to > underscore the fact that it might not be 64 bits. > > > If the proposed patches are OK, then the best is to apply them to > > master and I will remove the corresponding ones from the Y2038 series > > > > I don't think we're ready to start installing these into master, since I > still don't fully understand how difftime (much less mktime) will work. > Also, I want to make sure that the patches will be compatible with > Gnulib. It may make more sense to change Gnulib first, as it is less > formal about this sort of update. Since you want the changes in gnulib first, then I suspect I should provide branches above gnulib as well as above glibc? If so, what would you recommend as a good source on setting up a build and test setup for gnulib, similar to build-many-glibcs.py is for glibc? Cordialement, Albert ARIBAUD 3ADEV