Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250407024542.GR1827@brightrain.aerifal.cx>
Date: Sun, 6 Apr 2025 22:45:43 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: ipedrosa@...hat.com, musl@...ts.openwall.com
Subject: Re: strptime("UTC", "%Z", &tm) in musl

On Sun, Apr 06, 2025 at 09:57:35PM +0200, Alejandro Colomar wrote:
> Hi Rich,
> 
> I was trying to develop a function that parses a UTC date in the shadow
> project, and I came up with this:
> <https://github.com/shadow-maint/shadow/pull/1217/>
> 
> 	$ grepc -htfd get_date .
> 	static long
> 	get_date(const char *s)
> 	{
> 		struct tm   tm;
> 		const char  *p;
> 
> 		bzero(&tm, sizeof(tm));
> 
> 		p = strptime("UTC", "%Z", &tm);
> 		if (p == NULL || !streq(p, ""))
> 			return -1;
> 
> 		p = strptime(s, "%F", &tm);
> 		if (p == NULL || !streq(p, ""))
> 			return -1;
> 
> 		return dategm(&tm);
> 	}
> 
> Which works fine in glibc, but fails in musl.
> 
> 	$ grepc -tfd strptime . | sed -n '/case .Z.:/,/break/p'
> 		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++;
> 			}
> 			break;
> 
> It seems "%Z" only accepts the timezone specified in the current locale
> (via tzname), but doesn't accept parsing a different timezone (in this
> case, I want specifically UTC, regardless of the locale).  I'd say this
> is a bug, and an important limitation, BTW.
> 
> Is there any way I can workaround this for musl?

See commit fced99e93daeefb0192fd16304f978d4401d1d77. The newly added
specifiers were added only with their POSIX-specified behavior, not
anything else. I don't think the POSIX-specified behavior is terribly
useful, but it's indicative that there's not consensus on any behavior
beyond that, and that programs that depend on any particular
implementation behavior beyond what's specified are likely not
portable.

I'm not sure what you're trying to achieve so I don't know what
alternative I'd recommend.

Rich

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.