[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d213c51e-25ad-4cac-9cce-c00bcdf7b3d5@iki.fi>
Date: Mon, 23 Mar 2026 21:06:15 +0200
From: Hannu Nyman <hannu.nyman@....fi>
To: musl@...ts.openwall.com
Subject: Re: strptime in 1.2.6 - is tzname[0/1] guaranteed to be set?
Rich Felker kirjoitti 23.3.2026 klo 19.38:
> On Mon, Mar 23, 2026 at 06:38:07PM +0200, Hannu Nyman wrote:
>> Rich Felker kirjoitti 23.3.2026 klo 17.51:
>>> On Mon, Mar 23, 2026 at 04:15:09PM +0100, Szabolcs Nagy wrote:
>>>> * Rich Felker <dalias@...c.org> [2026-03-23 11:04:37 -0400]:
>>>>> On Mon, Mar 23, 2026 at 11:00:02AM -0400, Rich Felker wrote:
>>>>>> On Mon, Mar 23, 2026 at 08:19:43AM +0100, Szabolcs Nagy wrote:
>>>>>>> * Rich Felker <dalias@...c.org> [2026-03-22 21:39:01 -0400]:
>>>>>>>> char *strptime(const char *restrict s, const char *restrict f, struct tm *restrict tm)
>>>>>>>> {
>>>>>>>> int i, w, neg, adj, min, range, *dest, dummy;
>>>>>>>> - const char *ex;
>>>>>>>> + const char *ex, *s1;
>>>>>>>> size_t len;
>>>>>>>> int want_century = 0, century = 0, relyear = 0;
>>>>>>>> while (*f) {
>>>>>>>> @@ -207,16 +208,10 @@ char *strptime(const char *restrict s, const char *restrict f, struct tm *restri
>>>>>>>> s += 5;
>>>>>>>> break;
>>>>>>>> case 'Z':
>>>>>>>> - if (!strncmp(s, tzname[0], len = strlen(tzname[0]))) {
>>>>>>>> - tm->tm_isdst = 0;
>>>>>>>> - s += len;
>>>>>>>> - } else if (!strncmp(s, tzname[1], len=strlen(tzname[1]))) {
>>>>>>>> - tm->tm_isdst = 1;
>>>>>>>> - s += len;
>>>>>>>> - } else {
>>>>>>>> - /* FIXME: is this supposed to be an error? */
>>>>>>>> - while ((*s|32)-'a' <= 'z'-'a') s++;
>>>>>>>> - }
>>>>>>>> + s1 = s;
>>>>>>>> + i = __tzname_to_isdst(&s1);
>>>>>>>> + if (i>=0) tm->tm_isdst = i;
>>>>>>>> + s = s1;
>>>>>>>> break;
>>>>>>> what is the point of
>>>>>>>
>>>>>>> s1 = s;
>>>>>>> foo(&s1);
>>>>>>> s = s1;
>>>>>>>
>>>>>>> seems equivalent to
>>>>>>>
>>>>>>> foo(&s);
>>>>>> If you try that you'll see why it fails. But I think C admits a clean
>>>>>> version that works..
>>>>> Yep, the attached is good. I thought it would be bad to put a
>>>>> requirement that the caller's pointer be restrict-qualified into the
>>>>> signature of __tzname_to_isdst, but C allows the pointed-to type to be
>>>>> more qualified than the addressed object, so passing a pointer to a
>>>>> const char * would still be valid even with this change.
>>>> ...
>>>>> +int __tzname_to_isdst(const char *restrict *s)
>>>> ah, restrict is ugly, but it is what it is.
>>>>
>>>>> +{
>>>>> + size_t len;
>>>>> + int isdst = -1;
>>>>> + LOCK(lock);
>>>>> + if (tzname[0] && !strncmp(*s, tzname[0], len = strlen(tzname[0]))) {
>>>>> + isdst = 0;
>>>>> + s += len;
>>>> i'd expect
>>>> s += len
>>>> to become
>>>> *s += len
>>>> after the code move.
>>> Thanks for catching that. I should have renamed the variable when
>>> moving the code and changing its type so that this would have been
>>> caught. But now it's fine.
>>>
>> I get a bit lost with the last response, as there was no new patch attached.
>>
>>> Thanks for catching that. ... But now it's fine.
>> Is a new patch version still coming, or was the last one ("the attached is
>> good") already fine?
> Here's a fixed one,
>
Thanks.
I applied the patch and I compiled a firmware for two different routers.
Based on quick testing, the patch works ok.
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.
