[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6cd4c513-fb10-4214-8082-0a03a8f3cdd3@iki.fi>
Date: Mon, 23 Mar 2026 18:38:07 +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 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?
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.
