From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id CA2802244E for ; Tue, 26 Mar 2024 00:13:23 +0100 (CET) Received: (qmail 5578 invoked by uid 550); 25 Mar 2024 23:08:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5523 invoked from network); 25 Mar 2024 23:08:36 -0000 Date: Mon, 25 Mar 2024 19:13:28 -0400 From: Rich Felker To: Thorsten Glaser Cc: musl@lists.openwall.com Message-ID: <20240325231328.GL4163@brightrain.aerifal.cx> References: <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Broken mktime calculations when crossing DST boundary On Mon, Mar 25, 2024 at 10:40:01PM +0000, Thorsten Glaser wrote: > >> > Causing a program to loop or stack overflow. > > That’s because your application violates the constraints > that bind both, not just the libc, to the spec. It's not a constraint violation. mktime is required to accept inputs where the fields of the broken-down time don't fall within their respective ranges, and normalize them. Rather, the calling code is just making incorrect assumptions about the unspecified way that happens, and it only happens to "work" on glibc because glibc is erroring out in the middle of a computation, giving a partial result, rather than fully normalizing it. > >Output from musl: > > > >2011-12-29 01:00:00 -10 > > > > tm.tm_mday += 1; > > t = mktime(&tm); > > > >2011-12-29 01:00:00 -10 <-- date is the same after incrementing > > This is… not as incorrect as you state. > > The steps here are: > > • 2011-12-30 01:00:00 ← input > • 2011-12-30 01:00:00 ← input after normalisation (!) > • conversion to time_t (1325206800), application of timezone offset > • detection of the discontinuity between 2011-12-29 23:59:59 and > 2011-12-31 00:00:00 > • arbitrary choice of selecting either endpoint > > tbh I’d expect this to end up in 1325239199=2011-12-29 23:59:59 > instead of 2011-12-29 01:00:00 though, at least from reading the > latest Issue 8 proofreading draft. WDYT dalias? No, there is no clamping involved and I don't see how that would be useful or conforming. This is all underspecified, but basically, mktime is required to interpret out-of-range values for some fields as a denormalized time of sort and normalize it via a sort of division algorithm to a valid calendar time. What happens is that, when the local time is in the gap not covered by either adjacent timezone rule, we make an arbitrary choice to interpret it as a denormal in the later of the two adjacent rules, which then normalizes into a time in the earlier range. Here, 2011-12-30 gets interpreted as "1 day below 2011-12-31", which is 2011-12-29. Rich