From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id 8DA373858004 for ; Mon, 31 May 2021 19:03:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8DA373858004 Received: by mail-qk1-x72c.google.com with SMTP id q10so12032568qkc.5 for ; Mon, 31 May 2021 12:03:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0UGFpbURFjRqFxd5yONjuythj7SEzL7JvyTK4THRTx0=; b=Z/LQWJUOGirdLunkAM9fJZDKHncIOSCcDA4ySPYchNZBagUKKtTnDpnSUhfwXFDEBw L9j2hoNLhnooEn1noJjDa211AwSo26x2CNZGLY0EltDbEOGY/L90tUduPVFFbKY9f665 m6GkdlU1cfDUKlnMt+sPB6sCORL7z/p1hyj4NxvrphadxCHL2e58DSFKzTrvXaOAnWUR 8u8d9wSsMyzlTA40ewTZiYGW7Dy2S4PE1/VAsO/UM2WovOSN47ER4/XWL1Tc4BmbJQIR /O6tgk1ohoC/+R+x3a7Bn10IGafkwJ37FhCR1Z1LpomLMaeNVMDxc8IDrQJY0E06tH+o 66bg== X-Gm-Message-State: AOAM530Sn8VUT4YnyZkB1FIIHkkenopPdWsk+1IjwKe/ySJmP6gvHl+l k4u/BQN52I8lDrWvIVNc+ARjUg== X-Google-Smtp-Source: ABdhPJwtvip4CZC0SeT/fp1FIOiFefxwiEraSR4kwh7TlU7lm7Tsgky1uhxb+x5PXqgP97MxIGu/HA== X-Received: by 2002:a37:b15:: with SMTP id 21mr7938510qkl.136.1622487815912; Mon, 31 May 2021 12:03:35 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id r18sm8783071qtp.86.2021.05.31.12.03.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 May 2021 12:03:35 -0700 (PDT) Subject: Re: time64 functions for glibc To: Paul Eggert Cc: Elmar Stellnberger , libc-alpha@sourceware.org, libc-maintainers@gnu.org References: <8bb369a7-ebc0-d108-ca38-0ba2c658df12@elstel.org> <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> From: Adhemerval Zanella Message-ID: Date: Mon, 31 May 2021 16:03:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 19:03:38 -0000 On 31/05/2021 15:46, Paul Eggert wrote: > On 5/31/21 9:01 AM, Adhemerval Zanella via Libc-alpha wrote: >> It is on 2.34 plan [1], Carlos O'Donnel is reviewing it.  Similar to LFS, >> you will need a newer flag to actually enable it (-D_TIME_BITS=64). > > One place where Microsoft got it right and we're arguably getting it wrong, is that 64-bit time_t is the default on 32-bit MS-Windows, where one must opt into 32-bit by #defining _USE_32BIT_TIME_T. > > It's too late in 2.34 to make 64-bit time_t the default, but we should at least document that 64-bit time_t is planned to be default in the future. That is, programmers should not *rely* on 32-bit being the default. > > Obviously 64-bit will have to be the default eventually. (Rumors of x86 dying out completely before 2038 are exaggerated; some 32-bit software will likely live on past 2038 even if 32-bit-only chips are no longer made.) We should warn developers about that now. > > Since making 64-bit time_t the default also means 64-bit off_t will be the default, we should warn developers about that too. Yes, this is BZ#13047 [1] and BZ#14106 [2]. The BZ#14106 would require to move the current LFS to compat symbols and add newer double underscore ones for the affected architectures (and it is really messy that LFS supported for architecture with current 64 off_t support added alias symbols). But I think we should move to make LFS and 64 bit time_t default even without BZ#14106 fixed, maybe this is still time for 2.34. In any case, my plan is to fix on 2.35. > > Proposed patch attached, relative to the azanella/y2038 branch. Thanks, the patch looks reasonable and I will add merge on the patch that enable the y2038 symbols. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=13047 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=14106