From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24271 invoked by alias); 10 May 2018 02:04:14 -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 24261 invoked by uid 89); 10 May 2018 02:04:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] Use 64-bit time_t for time zone file parsing To: Florian Weimer , Andreas Schwab Cc: GNU C Library , Albert ARIBAUD References: <264af3e6-84ae-d1a4-c204-c00786b61dd9@redhat.com> From: Paul Eggert Message-ID: Date: Thu, 10 May 2018 02:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-05/txt/msg00433.txt.bz2 On 05/08/2018 07:29 AM, Florian Weimer wrote: > Ah. I'm dropping the check of BYTE_ORDER.=20 Thanks, this looks good to me. One minor suggestion. This line: =C2=A0=C2=A0=C2=A0 =C2=A0 i =3D (transitions[num_transitions - 1] - timer)= / 15778476; is now trickier than it used to be. Although the code still works since=20 it's just computing a guess, this new behavior might be worth a comment,=20 something along the lines "If size_t is 32 bits the assignment to I=20 could in theory overflow and wrap around, but this is harmless."