This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: unsetenv() patch for TZ
- From: Craig Howland <howland at LGSInnovations dot com>
- To: <newlib at sourceware dot org>
- Date: Mon, 30 Mar 2015 15:56:40 -0400
- Subject: Re: unsetenv() patch for TZ
- Authentication-results: sourceware.org; auth=none
- References: <3862C5643B15B6468269546753EB2A92055821DD at BLTSXVS01 dot govsolutions dot com> <20110709121946 dot GM4726 at calimero dot vinschen dot de> <51B1001E dot 9000805 at LGSInnovations dot com> <20130607102308 dot GA32420 at calimero dot vinschen dot de> <55196E10 dot 7050705 at LGSInnovations dot com> <20150330193057 dot GD13285 at calimero dot vinschen dot de>
On 03/30/2015 03:30 PM, Corinna Vinschen wrote:
On Mar 30 11:38, Craig Howland wrote:
...
Thanks. The setenv change is ok, but I have a bit of a problem with the
implemention in the time functions. Apart from the strftime 'z' case,
all calls to tzset are outside the TZ_LOCK/TZ_UNLOCK bracket, but tzset
calls TZ_LOCK/TZ_UNLOCK, too. As far as I can see it would be better to
implement _tzset_unlocked/_tzset_unlocked_r and call these from inside
the TZ_LOCK/TZ_UNLOCK bracket, wouldn't it?
I put the tzset() calls outside of the TZ locks to avoid deadlock, but put them
as close as possible to the TZ_LOCK to minimize the time, even though it is not
really required. This is because POSIX says "If a struct tm broken-down time
structure is created by localtime() or localtime_r(), or modified by mktime(),
and the value of TZ is subsequently modified, the results of the %Z and %z
strftime() conversion specifiers are undefined, when strftime() is called with
such a broken-down time structure." This gives a clear out to not needing to
lock tzset() atomically with the other strftime() internals, as it is required
of the user to not change TZ. I had considered this when making the patch, but
failed to mention it in the submission. The same thinking directly extends to
the other functions, when you think about it. (If the user is changing TZ a
lot, they need to ensure sequencing, whether it is strftime() or other functions
that rely on it.) So while we could make it more complex per your suggestion, I
don't think it is necessary.
Btw., was there some (historical?) reason that _setenv_r called tzset,
and not _tzset_r?
I don't know. Probably just being sloppy, like me when I copied the same thing.
Corinna