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.9 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,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 CAD4821161 for ; Sat, 23 Mar 2024 13:00:51 +0100 (CET) Received: (qmail 11824 invoked by uid 550); 23 Mar 2024 11:56:10 -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 11791 invoked from network); 23 Mar 2024 11:56:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711195237; x=1711454437; bh=MztuZb619wDUQBKtkAujOtDo/h0wsosgjZ7EpFqlUgQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aNDeXACgD9ifKXpR4xeps8NmId3lP9FbmNUk8F5oNoiphaCvnpqKwPK7obwFWl6Zi qZ5y2Ou+cpXZErZXBhoY9Y1E/IhoWbtZ0ohwOYeOB3klN4/lvGbRsaTDaXZZdmPV92 ixPVZKgNoHj9rGaD9oVvWlHEyvkg7MkbaEXaXtDpuPWnXDnIE4XxgweBe595oFk+/B AVAe744bH/OtJCKwloAF1D4JUKxtxa434xgR/iGFbazgOBRrxF/72Y4hEjtlbHVtYn r6coYKjxis2UDLXbKJPIyVR1+eu20e+U3gd8l7a7mOKvQWRIvlQ/raEitnBv3Q94YC uxp3zy1wB+8SQ== Date: Sat, 23 Mar 2024 11:59:56 +0000 To: Markus Wichmann From: Alexander Weps Cc: musl@lists.openwall.com Message-ID: In-Reply-To: References: <528SeRFaPfDw7fA4kqKDlio1U4RB_t9nmUemPcWw9_t1e2hBDpXYFmOqxAC37szgYvAVtmTuXWsmT64SSN3cSQFVdrQqXUAgkdTMPZQ0bg0=@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 > You don't need to set yday or the others before calling mktime(). I thought that too, but wanted to test it on exactly the same struct tm. No= change in behavior. So I have found a minimal example: void test() { time_t t; struct tm tm =3D {0}; char buf[64]; tm.tm_year =3D 2024 - 1900; tm.tm_mon =3D 3 - 1; tm.tm_mday =3D 31; tm.tm_hour =3D 1; tm.tm_min =3D 59; tm.tm_sec =3D 2; print_tm(&tm); mktime(&tm); strftime(buf, sizeof buf, "%F %T %Z", &tm); printf("before: %s\n", buf); tm.tm_isdst =3D -1; // This is the cause. tm.tm_min +=3D 1; mktime(&tm); strftime(buf, sizeof buf, "%F %T %Z", &tm); printf("after: %s\n", buf); } Setting tm_isdst to -1 after first mktime and before second mktime causes t= he issue. AW On Saturday, March 23rd, 2024 at 11:38, Markus Wichmann = wrote: > 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