From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 18:38:25 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB24316A421; Sun, 8 Jul 2007 18:38:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2FD13C4BD; Sun, 8 Jul 2007 18:38:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l68IcOpJ091549; Sun, 8 Jul 2007 22:38:24 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1183919904; bh=fhF5eg3+Rsx9i26lw0qzVu8jiMmcU9ygjV7fods lQmY=; l=2079; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=nE/NjC0d4aub7O0N91Ma 9WjKBCq8oXD0r17qFk9jqUcgh5GEgRjxi/T4f6PpzPyOQg6QmTzy1mP9u+LY1zcS03Q ZEIGo1NxO2i0XN3H+vIYk6suTSp+6D62VFlfBPwFt1JBn0bW1BGtzYcK7H9tRZWsqW9 YnOXdIuWjou9NuNB8= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l68IcNh2091548; Sun, 8 Jul 2007 22:38:24 +0400 (MSD) (envelope-from ache) Date: Sun, 8 Jul 2007 22:38:23 +0400 From: Andrey Chernov To: "Sean C. Farley" Message-ID: <20070708183823.GA91359@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070708125905.F14065@thor.farley.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070708125905.F14065@thor.farley.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current , Robert Watson , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 18:38:26 -0000 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/