From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120472 invoked by alias); 22 May 2018 22:10:04 -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 120454 invoked by uid 89); 22 May 2018 22:10:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=Hx-languages-length:1031 X-HELO: relay1.mentorg.com Date: Tue, 22 May 2018 22:10:00 -0000 From: Joseph Myers To: Paul Eggert CC: Albert ARIBAUD , Florian Weimer , Subject: Re: [[PATCH RFC 2] 02/63] Y2038: add function __difftime64 In-Reply-To: <0c2702d2-fe4b-125f-7dc4-c649aa6747d8@cs.ucla.edu> Message-ID: 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> <20180503193056.0ded171f@athena> <6f29bd3f-6d2f-f6d6-4efd-a46f2b1cf5fa@cs.ucla.edu> <20180522225805.695d3175@athena> <0c2702d2-fe4b-125f-7dc4-c649aa6747d8@cs.ucla.edu> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-05/txt/msg00745.txt.bz2 On Tue, 22 May 2018, Paul Eggert wrote: > As I recall, there were other unnecessary duplications in the proposed set of > patches, so this is not just an issue of difftime. Indeed. The global approach should be: the main implementation of any functionality that involves nontrivial implementation code in glibc is the one that uses 64-bit time, unconditionally, on all platforms. On platforms that currently have 32-bit time_t, the public interfaces for 32-bit times would become thin wrappers round those for 64-bit times while new public ABIs are added for 64-bit times (on platforms that currently have 64-bit time_t, there would be no new ABIs). If kernel support for 64-bit times is not known to be available for the (architecture, kernel version) pair for which glibc is built, the implementations in terms of 64-bit times may then need to translate back to 32-bit times, with overflow checks, to call into the kernel. -- Joseph S. Myers joseph@codesourcery.com