[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260323155133.GE1827@brightrain.aerifal.cx>
Date: Mon, 23 Mar 2026 11:51:34 -0400
From: Rich Felker <dalias@...c.org>
To: Hannu Nyman <hannu.nyman@....fi>, musl@...ts.openwall.com
Subject: Re: strptime in 1.2.6 - is tzname[0/1] guaranteed to be set?
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.
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.
