unsetenv() patch for TZ
Mon Mar 30 20:19:00 GMT 2015
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.
More information about the Newlib