I have to apologize, I confused the English terms.
I meant that getenv returns a pointer to static storage on some
platforms like the z/OS USS and calling it twice from the same thread
returns the same pointer. For instance, suppose the environment
variables foo and bar are both set, then after
char *foo = getenv("foo");
char *bar = getenv("bar");
foo will always be the same as bar (i.e. foo == bar). Now if I use APR
(pseudo code)
char *foo = apr_env_get("foo");
char *bar = apr_env_get("bar");
if apr_env_get would pstrdup the string returned by getenv I could
compare foo with bar, like this if (strcmp(foo, bar) == 0) ...Sorry again for my ignorance, I should have looked up the terms first. -- Ignaz 2011/9/12 Ignaz Birnstingl <[email protected]>: >> [un]setenv/putenv are never thread safe. You are confusing the issues, >> if the environment is volatile after threads are created the code is >> broken. > You are right, they are never thread-safe. However if apr_env_get > would pstrdup the returned value that would at least make it > reentrant. > >> Your 'fix' has a race condition and is therefore not the solution. > That's what I meant with "the documentation should probably state that > the function is not thread-safe and requires external serialization." > But at second thought thread-safety is documented nowhere for APR so > this can be omitted. >
