[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yf9tAroDB-Og6dyI5Ccs_aEwhmPuBXvmzllVAtyGCZSlAij_zgUHJyojz0fF-c9kudgI5mSVbFv6iwiPTeywz0lRgtUnLkoQJGw4It22YLg=@pm.me>
Date: Sat, 23 Mar 2024 11:59:56 +0000
From: Alexander Weps <exander77@...me>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: 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 = {0};
char buf[64];
tm.tm_year = 2024 - 1900;
tm.tm_mon = 3 - 1;
tm.tm_mday = 31;
tm.tm_hour = 1;
tm.tm_min = 59;
tm.tm_sec = 2;
print_tm(&tm);
mktime(&tm);
strftime(buf, sizeof buf, "%F %T %Z", &tm);
printf("before: %s\n", buf);
tm.tm_isdst = -1; // This is the cause.
tm.tm_min += 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@....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 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
