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
--- Original message ---
From: Ignaz Birnstingl ign...@gmail.com
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) ...
Bojan,
I'm totally aware of that and that's what I said in previous mails.
However there is IMHO no way to make this API thread-safe since it
uses a non-thread-safe API in the first place. Suppose we would use
internal serialization by using an APR mutex inside all APR
environment functions, that
I guess the patch didn't make it to trunk so I'll restate why I think
this should make it to future versions of APR:
-) The documentation says about argument pool: where to allocate
value and any temporary storage from. If *value is not allocated from
pool then manipulating the data pointed to it
On 9/12/2011 2:38 AM, Ignaz Birnstingl wrote:
I guess the patch didn't make it to trunk so I'll restate why I think
this should make it to future versions of APR:
-) The documentation says about argument pool: where to allocate
value and any temporary storage from. If *value is not allocated
[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
