On Wed, 4 Jul 2007, Sean C. Farley wrote: > On Wed, 4 Jul 2007, Andrey Chernov wrote: > >> On Wed, Jul 04, 2007 at 06:36:42PM +0400, Andrey Chernov wrote: >>> 2) "s" may point to getenv()-provided value there. So just modifying it >>> directly followed by setenv() call will make things inconsistent. >>> >>> 3) In my version of patch there was savestr() which copy arg to avoid this >>> situation. >>> >>> Fix will be to restore var.c to mine variant 1.34 >> >> You may also try this patch against var.c 1.36: > > Andrey, thank you. > > Sorry for the bug everyone. Here is a patch that should fix it: > http://www.farley.org/freebsd/tmp/setenv/sh.patch I assume I'm not the only person with this concern, but -- shouldn't we worry that subtle changes in the semantics of very basic and widely used system APIs might not result in more of exactly this sort of problem? While I'm supportive of the general aim of improving the portability of our APIs, environmental variables are managed by large numbers of programs in rather subtle ways--do we generally feel that this recent work will decrease or increase the number of subtle bugs? After all, we've changed long-standing semantics for the APIs... Robert N M Watson Computer Laboratory University of CambridgeReceived on Wed Jul 04 2007 - 14:41:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:13 UTC