From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7479 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: setenv if value=NULL, what say standard? Bug? Date: Wed, 22 Apr 2015 22:52:09 -0700 Message-ID: <20150423055208.GA3909@newbook> References: <553837F1.5080808@safe.ca> <55383E43.8010505@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1429768351 19444 80.91.229.3 (23 Apr 2015 05:52:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 05:52:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7492-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 07:52:20 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YlA3f-0006va-Up for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 07:52:20 +0200 Original-Received: (qmail 21805 invoked by uid 550); 23 Apr 2015 05:52:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21784 invoked from network); 23 Apr 2015 05:52:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=GfWQBwiVWXUiCgbBObmDt1PsQR4tT4PR51+2rbisqgQ=; b=ZYAPZqhBftJ86KPvy0ZmnYUl66Qir3ww8baaDUpsAnT8/hUMUigKrxXr8paZUjFwOV L18ktm/W7VhIYhwyzmyVdoOW7rnORALhVtui224TzWqsxU7xVQYXWLUYlwwgJJwGX3fr WR+hHCHktcfabsJ5qBSWrQR1OX2KY0d08zVIOxLE59wqj+2J2iOF0gietGWzwr6Pt+QT mw5QeZVOzxk2IXQh682HgalGt0ddJS9bTxY8aUgW7JsmlePBLbI7HPMApG7YLpvtFVep 44T6i8PFEknJhupvBK9i6Uez1qW7400GttznCTILGp4grOi8rSARZJfR39VgFxcUM21n xlYA== X-Received: by 10.68.223.130 with SMTP id qu2mr2222642pbc.116.1429768326011; Wed, 22 Apr 2015 22:52:06 -0700 (PDT) Content-Disposition: inline In-Reply-To: <55383E43.8010505@skarnet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7479 Archived-At: On Thu, Apr 23, 2015 at 02:35:15AM +0200, Laurent Bercot wrote: > On 23/04/2015 02:08, Jean-Marc Pigeon wrote: > >My guess, glibc code is 'blindly" setting the NULL (as "") > >value to the variable. > > > >Is the standard saying otherwise, or do we have a > >a real bug in setenv?? > > The standard at > http://pubs.opengroup.org/onlinepubs/9699919799/functions/setenv.html > says... > > ... exactly nothing about the possibility of envval being NULL. > This is, in the strictest sense, UB. :) > > Actually, it says "The environment variable shall be set to the value > to which envval points." So, arguably, envval should point to something, > and since NULL does not, it is forbidden. Another valid interpretation > could be that envvar is set to the value to which envval points, i.e. > no value at all, so it is unset; but it doesn't fit the spirit of > setenv() to unset variables. The glibc interpretation, if it does what > you think it does, is wrong in any case: the empty string is a very > different thing from no value at all. > > I think the only safe conclusion is that the application is incorrect > and should ensure that setenv() is never called with a NULL value. I happen to have just reread http://www.tedunangst.com/flak/post/zero-size-objects which has this little bit of information: The C standard has this to say in the section on “Use of library functions”. If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, [...]) [...], the behavior is undefined. The section on “String function conventions” clarifies further. Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values. In other words, passing a NULL pointer is undefined behavior unless spelled out to the contrary, even if a good implementation would have no reason to follow it. Now, setenv() is part of POSIX rather than ISO C, and thus has its own rules, but ISO C is the foundation. As to the question of what's the "right" thing to do, consider these two function calls: setenv("OTHERVAL", getenv("SOMEVAL"), 1); strcmp(getenv("OTHERVAL"), getenv("OTHERVAL")); It should be obvious that the second is incorrect. But it's easy to arrive there if the former is accepted. So I've sent a patch for this to the util-linux list. Thanks, Isaac Dunham