From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24453 invoked by alias); 21 Jun 2018 21:17:29 -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 24443 invoked by uid 89); 21 Jun 2018 21:17:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH 1/1] Y2038: add function __difftime64 To: Albert ARIBAUD Cc: libc-alpha@sourceware.org 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> From: Paul Eggert Openpgp: preference=signencrypt Message-ID: <31f71b4a-6141-f27a-3385-3653f58adb28@cs.ucla.edu> Date: Thu, 21 Jun 2018 21:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180620225545.4eb76291@athena> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00694.txt.bz2 On 06/20/2018 01:55 PM, Albert ARIBAUD wrote: > >>> This change batch creates a __difftime64 compatible with 64-bit time, >>> and makes difftime either an alias of it or a 32-bit wrapper around it. >> 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. > 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.