apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignaz Birnstingl <ign...@gmail.com>
Subject Re: Fwd: [PATCH] apr_pstrdup value returned by apr_env_get
Date Tue, 13 Sep 2011 06:47:37 GMT
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.


2011/9/12 Ignaz Birnstingl <ignazb@gmail.com>:
>> [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.

View raw message