From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id BF91F1F462 for ; Mon, 29 Jul 2019 23:31:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=RgoNm YijmC+b0bayFPwpgL4VPXk6An6sErqh548+bnNNi67q+TeE51Lfzzbbp8RZGuIif hBibV5bjOdRrVqOTJMLOA75oVzJ5nLOPH35o9xLGVsT43YnAZPXvT53unDyg36tT KziEU9Cy2rJfNhVqp/tbJUMXA9Bys9XtxImFEw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=ivGxSiOfPmt 2K4XIN9TNLA5dV4s=; b=m7PXFI5eL6gnT3hilMJDsvpvu+t0fs67YLHvDQFxd6B w+A6vgIbhzbS3hDKmHUq8MSqtboE3v/qQ4Ulz+T4vGK2n1NrDrdqqOo5YfiUN757 LmF7QUOXL02w8imv6maXAKqeT1UdHYGiDCgCECaptVdhvBDqZ6bbTuCHyJMA8Lo8 = Received: (qmail 21799 invoked by alias); 29 Jul 2019 23:31:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 21649 invoked by uid 89); 29 Jul 2019 23:30:41 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Mon, 29 Jul 2019 23:30:16 +0000 From: Joseph Myers To: Paul Eggert CC: Adhemerval Zanella , Subject: Re: Accelerating Y2038 glibc fixes In-Reply-To: Message-ID: References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> <43e70b10-c1a1-ca79-b596-60616c8f5ad6@linaro.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Mon, 29 Jul 2019, Paul Eggert wrote: > On 7/29/19 4:08 PM, Joseph Myers wrote: > > > What it would require is to add compat implementations with a different > > > type, time32_t for instance. Something like: > > That seems much harder to implement through incremental development, > > whereas with _TIME_BITS=64 things can readily be implemented incrementally > > I worry that this puts the incremental cart before the incremental horse, at > least for portable applications. If we take the _TIME_BITS=64 approach, > portable applications should add the equivalent of "#define _TIME_BITS 64" to > their config.h files or ihatever, because they should be Y2038-safe. But if > glibc development is incremental so that some time_t uses are glitchy when > _TIME_BITS=64, these applications will have problems. Conversely, if glibc > doesn't publicize the time_t changes until they're ready (which I think is the > intent), the _TIME_BITS=32 approach would be less hassle overall for portable > applications; they won't have to change their source code. Header support for _TIME_BITS=64 shouldn't be added until all functions fully support it. At that point, having it not be the default for some number of releases helps users plan the ABI transition for their libraries (rather than getting an ABI break by default for any library that gets rebuilt with newer glibc unless a special option is used, they can plan a whole-distribution transition on their own timescale). -- Joseph S. Myers joseph@codesourcery.com