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.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 9A7F7216E4 for ; Sat, 23 Mar 2024 11:39:04 +0100 (CET) Received: (qmail 6057 invoked by uid 550); 23 Mar 2024 10:34:23 -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 6020 invoked from network); 23 Mar 2024 10:34:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1711190328; x=1711795128; i=nullplan@gmx.net; bh=8MiHGqcGT7SRxWR/H+Eg4lHuLi1UgVJq+e43wP6EJbw=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=YLrfRO9E+1HR+TT6nQ5UPLrD1I4ZXf4ZGuzRMyaTqxg9bm+4zQhVxDFMYmHMPvFQ /9omcnkLF4Fu6aAdTnF4ROav+GsZ4LhFMVrt176uldbPGqnuXk0KcQjco2L1s+9TQ cvoImi9Ahs6eyeUYnUAky/htdD1YSSb6aZh7v0P/ZEYtFfK/kZ6z4wug44qv0T6Od IcwnBAd+YmcvJ+vT/vIh6uNZcs4Yb2COf6cSdAwm9asVPpnYNN26g637Nys0d5Fqg RPelel3HW1dn5GA1O0BtKHdqpe20GetRpvnRM2glsFipCQYoF+ZAVqDwJQzU+O8T7 i9SKvc1V/DhIqE2MnA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sat, 23 Mar 2024 11:38:46 +0100 From: Markus Wichmann To: Alexander Weps Cc: musl@lists.openwall.com Message-ID: References: <528SeRFaPfDw7fA4kqKDlio1U4RB_t9nmUemPcWw9_t1e2hBDpXYFmOqxAC37szgYvAVtmTuXWsmT64SSN3cSQFVdrQqXUAgkdTMPZQ0bg0=@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528SeRFaPfDw7fA4kqKDlio1U4RB_t9nmUemPcWw9_t1e2hBDpXYFmOqxAC37szgYvAVtmTuXWsmT64SSN3cSQFVdrQqXUAgkdTMPZQ0bg0=@pm.me> X-Provags-ID: V03:K1:R0I4dUWNZlTMxnE3F0YkdYqckBBe0vXrQNaZ4gVrcet/4EVUKWB Xf2Yh+mRfozLuMsJaavvWB0cUXhFfVdQvISccwYT1J7M88Fn4x84T1b8ayIrQ+AtwdvzDAX TOQBLjk/3AAS1iMsT5JrD3WWOeQPfpG8WZYTrjgHB8YmPFHMhYVwbya6vX29pA74v1f4aSn cElt8NlA9K3a9DqaAn4nA== UI-OutboundReport: notjunk:1;M01:P0:AZVvbhAf6oA=;7RGdroqsbWzvsir3dh8RWLhHJN7 r/fbYq8N72u36is47RjQNzQZjq9Cl/g1BSPENCwcTkOlrBB96nvl6s4zH8b/G8ADzqJID4IYy TBD4FH0bPggTB5fR6twNQtg5HgWkW/yM1zYAfeIeCAuHP1HxJv+EOzVDgBHDfxTD20SuexP79 CY/UF+7P4Y0Dn2+bA3dph8pd8sM++VPyM9fxYPGO2sLH5dww1nkF0bhI+Svy1Ipu/cpY6KAjg oztjRlVddImwsBSDuFLxPP4c2x34XsZnGS7bSQZi3qCN83xjwyNIgFiOf5xeUUf82bQo1j1fD VOhF719nV42isEY93rY4StIjnieGswMW//HlZPam7ZUpjL9MrxmrFRHJ9HFJ+kXB81J/qFisQ Znvey2HX7PmhseLm76bdMMqDvGl5EeK4HWYugHCTnQw8hkM86Xn0gLbz1siDCTpqHIZmS10Lt 96gAHsTRQvPSHYIfRD/scjv56+4c9gK16ip2qnmpnZtPywL2NzTUMxM16O1dOq6o19fpRb9w6 wDKoGK+bixHHf2GfNwmjqKkacXunNb13c8ktD4QZigIUZ8pttVm4/e2wDdEBmrwxb6dfQdUdm W5NaZesE9RL/DhwNg/CJpBuMAY2EYd3yt3fzrbpdE1GCsSxmeQEJQL1mfw7uEghs84QSy5tQe N9Hx/5RVV+D7FYgEwzHH9wZC6AOby3jvTQLdlrlZP7v9vHrOF2rRIfghrDOqZxUg9QTBkkUoE pcxcvqrayAUgPn2SRCXcbKUfTokNMlC+E484kkyguqRJcoCpIFmKxWNYUqwW4U02JAKHJYPc5 iNbWXXB5HxD5TiQAhP5GawDE4InTqfz2BXUjBkcxQmM2ugw19dTjbxx5xaI3efJRV0 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Broken mktime calculations when crossing DST boundary Am Sat, Mar 23, 2024 at 09:26:00AM +0000 schrieb Alexander Weps: > This works for me as well even after changes to match struct tm in my > app (setting tm_yday, __tm_gtmoff a __tm_zone): You don't need to set yday or the others before calling mktime(). mktime() is defined to only use year, mon, mday, hour, min, sec, and isdst as input, normalize them, and calculate the others (and also the UNIX time stamp). > > Any idea how could a previous calculation mess with musl internals so > it would start producing bad results? Because otherwise, I don't see > how this could be happening if you completely extract it out of the > code and it works. > The only thing that means is that the isolated code works, and the bug is elsewhere. I'm sorry, but you are going to have to debug this yourself. There may be some static memory getting corrupted (e.g. the TZ and rule caches), but honestly this is just speculation. > And when I compile under glibc, everything is fine. That tends to indicate some undefined behavior. Not that that helps you find the reason. You are going to have to debug it. Finding a minimum reproducer may help in that, or you directly apply liberal amounts of gdb. You seem to have dropped the list from CC, so I'm adding it back. Ciao, Markus