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 642BE2238A for ; Sat, 23 Mar 2024 13:01:50 +0100 (CET) Received: (qmail 16019 invoked by uid 550); 23 Mar 2024 11:57: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 15987 invoked from network); 23 Mar 2024 11:57:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711195297; x=1711454497; bh=G3bx1izd9UFVRDIuAC8YQBOeDefPKnny90LMhjtHo2E=; 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=S6l5ZNUJUOnaNWcmO1oAOVierHi9FPBEBvlUs06afa7fMHus7DCLFTc0pYZ6U5SXr OgoG6xKXMi+76ciBtmgKG9fSnvEmkC/68poAJnbQ8rOVjggvZIPb+BbWzdx9fG6E9Q das15rRZcLZS236nk7LgPXwP2vGumw0MBHhmg19lNvRUqUsMDbf2/x7IYHk2vCXkvH 3PkahdtbNdgFDmzAvlp9JsYoL9ttFIxa3hGa4ke/GVzazDsl8ZDBEK2mtp6OdiVP1X R7aJ4FBzqm66IGZyJEfy+LtjItS2J7ZrIDeKYt+vR8D7E+Sbz/coMoLWR5y02RQAGr eN+9i5sLVyNJQ== Date: Sat, 23 Mar 2024 12:01:31 +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 This is how it should work as far as I am concerned. After manipulating the= date, the tm_isdst is set to -1. >From https://cplusplus.com/reference/ctime/tm/: The Daylight Saving Time flag (tm_isdst) is greater than zero if Daylight S= aving Time is in effect, zero if Daylight Saving Time is not in effect, and= less than zero if the information is not available. And the date should be correctly set as DST or STD in mktime. I have a date. I make change in fields, I set tm_isdst =3D -1, I call mktim= e. I see only on place where tm_isdst is checked and that's: time_t mktime(struct tm *tm) { struct tm new; long opp; long long t =3D __tm_to_secs(tm); __secs_to_zone(t, 1, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_z= one); if (tm->tm_isdst>=3D0 && new.tm_isdst!=3Dtm->tm_isdst) t -=3D opp - new.__tm_gmtoff; t -=3D new.__tm_gmtoff; if ((time_t)t !=3D t) goto error; __secs_to_zone(t, 0, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_z= one); if (__secs_to_tm(t + new.__tm_gmtoff, &new) < 0) goto error; *tm =3D new; return t; error: errno =3D EOVERFLOW; return -1; } So tm->tm_isdst>=3D0 seems to be the cause here. AW On Saturday, March 23rd, 2024 at 13:00, Alexander Weps wr= ote: > > 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= the issue. > > AW > > > > > On Saturday, March 23rd, 2024 at 11:38, Markus Wichmann nullplan@gmx.net = 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 T= Z > > 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