On Sun, Jul 08, 2007 at 01:14:31PM -0500, Sean C. Farley wrote: > SUSv3 states that that is not a safe assumption to make. Read the > paragraph starting with "Conforming multi-threaded" from exec(3)[1]. It > basically equates direct use of the environ variable as the same as any > *env() call. >From my reading, not exactly so: "Conforming multi-threaded applications shall not use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable. A call to any function dependent on any environment variable shall be considered a use of the environ variable to access that environment variable." They say "while any other thread is concurrently _modifying_ any environment variable" but getenv() is not supposed to modify environ in any way. They cleary separate "access" and "modify" terms in this paragraph. >From getenv(): "The getenv() function shall _search_ the environment of the calling process" I.e. no "modify" word found in getenv() description (and whole manpage). Meanwhile, they say in getenv(): "If the application modifies environ or the pointers to which it points, the behavior of getenv() is undefined." So we are free here to do the most reasonable strategy (as undefined). Modifying environ is "undefined" too, of course, but not looks so reasonable. >> Could you please make setenv() wrapper like that to avoid modifying >> merged environ in the middle? >> __lsetenv(str, str_len, value) > > I could add this as a feature later. Unfortunately, unless I can lock > the use of environ, an application could do this even with the 6-STABLE > version of *env() functions. I have been pondering about thread-safety > in a future release of these functions (8-CURRENT), but it may not be > possible since environ is exposed. Even in case it may happens with 6-STABLE, we better not repeat the way lead to mistakes again :) > Sean > 1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html -- http://ache.pp.ru/Received on Sun Jul 08 2007 - 16:38:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC