On Sun, 8 Jul 2007, Andrey Chernov wrote: > On Sun, Jul 08, 2007 at 06:09:40AM +0400, Andrey Chernov wrote: >> On Sat, Jul 07, 2007 at 09:03:59PM -0500, Sean C. Farley wrote: >>> >>> Surprisingly, keeping the pointers saved time even if calling >>> setenv(). >> >> Ok. It feels like time to commit comes :) > > Hmm. I just think a bit more and feel worry about that place in the > merge code: > > *equals = '\0'; > if (setenv(*env, equals + 1, 1) == -1) > return (-1); > *equals = '='; > because it modifies memory which may be treated like const one. > > Consider following scenario: getenv() is not thread-safe, but may be > called by thread-safe app if it is sure no other *env() calls in > progress. In the same time another thread of this app use environ > directly say for exec(), assuming it is const. In the middle of that > getenv() modifies environ by *equals = '\0'; 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. > 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. Sean 1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html -- scf_at_FreeBSD.orgReceived on Sun Jul 08 2007 - 16:14:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC