This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html ,,The getenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe.''
Any code that relies upon getenv() being thread-safe is inherently non-portable. As the previous commenter points out, the POSIX and the UNIX standards specifications call out getenv() as not guaranteed to be reentrant. While this feature of your getenv() may have benefits, it's not usable in a portable environment.
Well of course that's all very nice, except that some care about *more* than *just* POSIX.
The "MT-Safe" putback to the Solaris libc was made on 92/05/06 (according to the SCCS history). We didn't ship a user-level threads library until 1993, which means Solaris has *always* provided a thread safe getenv().
The Pthreads specification *wasn't even ratified* until 1995 (Solaris 2.5 was shipped with support for Pthreads in November 1995).
When I came to tune getenv(), dropping thread safety simply *wasn't an option*. We could argue until the proverbial cows come home about the relative merits of getenv() thread safety. But that's not the point. We said we were for it. We have always shipped it. We must assume there are people who depend on it.
So, quote whatever standards you will! Our getenv() has always been thread safe, but it is now also *fast*! What's the problem? It's certainly not a problem for Solaris! If people need getenv() to be thread safe, they know where to come; if they don't, I think we've shown that we're here to compete.
On Mon, Aug 15, 2005 at 03:16:56AM -0700, Paul Orang wrote: > http://blogs.sun.com/roller/page/pgdh/20050614 points > out that glibc getenv is not protected against > parallel setenvs. Can it be fixed?
getenv is not required to be thread-safe, see http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html The string returned by getenv may become invalid after next setenv/putenv/unsetenv call, so any program relying on thread-safety of these is broken.
Jakub
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |