unsetenv() patch for TZ

[Craig Howland]

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
>