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=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 C1EC1217DD for ; Mon, 25 Mar 2024 12:52:34 +0100 (CET) Received: (qmail 13848 invoked by uid 550); 25 Mar 2024 11:47:49 -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 13816 invoked from network); 25 Mar 2024 11:47:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711367540; x=1711626740; bh=sRqYK6bIHb457Hqbs1dmzu1Um+N/fx8GyjMsl2a1eOg=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Gl3poxIzkQ5dIO2iV6R63LS1sK1bIJJy76ysbtC+HUdNExWWH9fYm1WOtIroKFrsw NSz+tNHYGHMKfD/8FtnQyLyPXfgVWOHwWQjnLYoAfD3eKWAGc35J9gjwMuJZRHgge2 MzN4yw4m3/+ARNWqU22lyngiBF7SkKn+6xvKfojuBwbREI9Mm7hGgaInZ+CEXFy9cj 8O1gsCmdR4IHhOzpBkrySQEJGbGEbVqQaLwqZ+PUf+pLuv45Y7ThCH9znU5ctCHIpX vfxaNmVpte2bvofgQLcwjOBcIHnEJIgAQCIxVdJPqYhtNtPiI8cmvyzoYv1cyQPWMl S5flWKpLJD+Gw== Date: Mon, 25 Mar 2024 11:52:00 +0000 To: musl@lists.openwall.com, Rich Felker From: Alexander Weps Message-ID: In-Reply-To: <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> References: <20240324180200.GW4163@brightrain.aerifal.cx> <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> Feedback-ID: 20507743:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Broken mktime calculations when crossing DST boundary This is the simplest and most obvious example how broken the calculation in= musl is: void test10() { time_t t =3D 0; struct tm tm =3D {0}; char buf[64]; tm.tm_year =3D 2011 - 1900; tm.tm_mon =3D 12 - 1; tm.tm_mday =3D 29; tm.tm_hour =3D 0; tm.tm_min =3D 0; tm.tm_sec =3D 0; tm.tm_isdst =3D 0; strftime(buf, sizeof buf, "%F %T %Z", &tm); printf("before: %s %ld %ld\n", buf, t, calc(&tm)); t =3D mktime(&tm); strftime(buf, sizeof buf, "%F %T %Z", &tm); printf("after1: %s %ld %ld\n", buf, t, calc(&tm)); tm.tm_mday +=3D 1; t =3D mktime(&tm); strftime(buf, sizeof buf, "%F %T %Z", &tm); printf("after2: %s %ld %ld\n", buf, t, calc(&tm)); } TZ=3DPacific/Apia Year is greater than 1970. Input: 2011-12-29 01:00:00 -10 Add a day: tm.tm_mday +=3D 1; t =3D mktime(&tm); Output: 2011-12-29 01:00:00 -10 Musl cannot reliably increment date by a day. Incrementing struct tm repres= enting 2011-12-29 01:00:00 -10 by one day leads to the same date. Causing a program to loop or stack overflow. AW On Monday, March 25th, 2024 at 01:36, Alexander Weps wrot= e: > I have no problem with the POSIX (Issue 8) or ISO C standard. > > I agree it doesn't mandate mktime making correct calculations, but I woul= d assume it is expected. > > AW > > > > On Monday, March 25th, 2024 at 00:51, Thorsten Glaser tg@mirbsd.de wrote: > > > Alexander Weps dixit: > > > > > You are describing the musl behavior, more specifically what I see in= mktime & __tm_to_secs. > > > I don't think this is correct behavior. > > > > This is what POSIX (Issue 8) and AFAIR also the next ISO C standard > > mandate, though: > > > > 1.=E2=80=936. struct tm is normalised from seconds or minutes up to yea= r > > 7. struct tm is converted to time_t (wrongly written down as > > =E2=80=9Cthe number of seconds since the epoch=E2=80=9D as it omits lea= p > > seconds) > > 8. timezone corrections for standard time at the moment in > > time calculated in step 7 is applied > > 9. if the timezone has DST: > > + if tm_isdst is positive, the time is adjusted by the offset > > + if tm_isdst is negative, the result is either the same as > > if it were 0 or the same as if it were 1; if the struct tm > > specifies a gap or repeated segment, which of the two is > > used is explicitly unspecified, i.e. the caller cannot rely > > on the libc to guess his intent if he sets tm_isdst to -1. > > 10. (not numbered) for gaps or repeats, mktime uses either the value > > from before the gap/repeat or the one after, choice again > > unspecified > > > > Tough luck there. > > > > The wording in this part is interesting though: > > > > | If tm_isdst is positive, mktime() shall further adjust the seconds > > | since the Epoch by the DST offset. > > > > But I guess that if you call with tm_isdst=3D1 and a broken-down time > > that clearly corresponds to n=C5=8Dn-DST, the DST offset for it is just= 0 > > and it=E2=80=99ll work out the obvious way. > > > > bye, > > //mirabilos > > -- > > =E2=80=9CIt is inappropriate to require that a time represented as > > seconds since the Epoch precisely represent the number of > > seconds between the referenced time and the Epoch.=E2=80=9D > > -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2