Threaded programs may crash randomly if strftime() and setenv() aren't excluded from being called in parallel, since getenv() is called from the inside of strftime(). While getenv()-setenv() thread safety problems are documented, it is not documented that time functions have these problems as well. The proposed patch introduces getenv_r() as a reentrant version of getenv() and uses it from inside of the time functions; maybe you'll choose a different approach (or a different name for the function or so), but something should be done about this. Also, maybe other parts of glibc making use of getenv() might need the same fix.
Created attachment 1676 [details] Proposed patch
(Forgot to mention that the patch was written only partially by me, a large part came from a customer of Novell.)
strftime is documented in POSIX that it acts as if it calls tzset(). And tzset is documented to inspect the TZ env variable. setenv is documented to be non-thread safe, what glibc does there is beyond what the standard requires. And this is IMHO the same thing.
Strictly speaking, it doesn't say that it inspects $TZ in a non-reentrant way (using getenv()), does it? But I agree that this is quite a nitpicking. But still, what are the considerations against integrating such a patch? Just the possible small performance penalty?
The environment cannot be made thread-safe. It's ridiculous that programs even use setenv() for purposes other then calling exec afterwards. There is no reason to jump through hoops and punish every program out there just because some people cannot program.