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: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 D724D1F8C6 for ; Sun, 4 Jul 2021 03:15:14 +0000 (UTC) Received: from localhost ([::1]:56596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lzsbB-0000bi-Fx for normalperson@yhbt.net; Sat, 03 Jul 2021 23:15:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzsb7-0000aH-Qp for bug-gnulib@gnu.org; Sat, 03 Jul 2021 23:15:09 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzsb5-0004wI-Ra for bug-gnulib@gnu.org; Sat, 03 Jul 2021 23:15:09 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B81211600E0; Sat, 3 Jul 2021 20:15:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 35KUeItiXz6E; Sat, 3 Jul 2021 20:15:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6932C1600E5; Sat, 3 Jul 2021 20:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BdpNCugkG2w9; Sat, 3 Jul 2021 20:14:59 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3280B1600E0; Sat, 3 Jul 2021 20:14:59 -0700 (PDT) To: Jay K References: From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#49269: gzip tru64 64bit time_t Message-ID: <934b4ef4-26be-4eec-5ba4-542b8ee185b0@cs.ucla.edu> Date: Sat, 3 Jul 2021 20:14:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gnulib bugs , 49269-done@debbugs.gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 6/29/21 2:21 AM in , Jay K wrote: > checking for 64-bit time_t... no > configure: WARNING: This package requires a 64-bit 'time_t' type if the= re is any way to access timestamps outside the year range 1901-2038 on yo= ur platform. Perhaps you should configure with 'CPPFLAGS=3D"-m64" LDFLAGS= =3D"-m64"'? >=20 >=20 > https://github.com/jaykrell/cm3/blob/master/m3-libs/m3core/src/m3core.h > suggests how: >=20 > #ifdef __osf__ > /* Request 64bit time_t. Not available on v4. Would be good to autoconf= this. > * We later check for TIMEVAL64TO32/TIMEVAL32TO64 to see if this works= . > */ > #ifndef _TIME64_T > #define _TIME64_T > #endif > #endif /* osf */ As I understand it, on Tru64 defining _TIME64_T does not make time_t 64=20 bits; it merely makes visible the type time64_t and related functions=20 time64, localtime64, etc. So if we wanted to support 64-bit time_t on=20 Tru64, we'd need something like this: #define _TIME64_T #define time_t time64_t #define time time64 #define localtime localtime64 ... which sounds error-prone. And since Tru64 doesn't seem to have a stat64=20 call, it wouldn't work for programs that need to use stat and similar=20 syscalls. Given that there's little chance to getting this sort of thing to work,=20 and that Tru64 is no longer supported (HP dropped support in 2012) I=20 doubt whether it's worth worrying about this problem for gzip, so I'll=20 close the bug report. You can simply ignore the configure-time warning=20 from now until 2038 (when Tru64 stops working for lots of other=20 reasons). However, I'll cc. this email to bug-gnulib in case someone=20 else can think of a better way to get this to work on this obsolete=20 platform.