From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id EC87E3858401 for ; Sat, 16 Oct 2021 00:20:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC87E3858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4D0DE160106; Fri, 15 Oct 2021 17:20:34 -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 ih92w59bUxev; Fri, 15 Oct 2021 17:20:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8FFC71600FD; Fri, 15 Oct 2021 17:20:33 -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 TeD0Dq0vb98d; Fri, 15 Oct 2021 17:20:33 -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 66EE91600EA; Fri, 15 Oct 2021 17:20:33 -0700 (PDT) To: "Alejandro Colomar (man-pages)" Cc: libc-alpha@sourceware.org, mtk.manpages@gmail.com, linux-man@vger.kernel.org References: <20211011111237.9414-2-alx.manpages@gmail.com> <15d7b96d-13d0-86c1-48f3-24a637ab8e30@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH v2 2/2] timegm.3: Remove recommendation against use of timegm() Message-ID: <38fa4e31-f70d-f3f3-e964-b4831b750271@cs.ucla.edu> Date: Fri, 15 Oct 2021 17:20:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Sat, 16 Oct 2021 00:20:36 -0000 On 10/15/21 3:03 PM, Alejandro Colomar (man-pages) wrote: > Actually, since timegm(3) is implemented in terms of mktime(3), as far = as I could read from glibc code, the problem will be the same, I think. No, because another thread could setenv ("TZ", ...) between the time=20 that you call mktime and the time you look at the 'timezone' variable.=20 So even though mktime itself is thread-safe, the expression 'mktime(tm)=20 - timezone' is not. > But timegm(3) shouldn't need to depend on environment variables. It does depend, if leap seconds are involved. >> and the subtraction might overflow. >=20 > Yup, casting to int64_t needed. That would help, but it still wouldn't suffice. It'd mishandle -1=20 returns, for example. Plus, we're better of not putting today's hardware=20 assumptions into code (suppose int is 64 bits in future machines?). > BTW, I had a look at mktime source=20 > code, and it uses long, which might be 32 bits, and then there's a lot=20 > of checking for overflow. mktime uses long_int, which is not necessarily 'long'. And no matter=20 what type you pick, it could overflow on some platform, even if it's an=20 only-hypothetical platform now.