From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7474 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: setenv if value=NULL, what say standard? Bug? Date: Wed, 22 Apr 2015 22:15:07 -0400 Message-ID: <20150423021507.GG6817@brightrain.aerifal.cx> References: <553837F1.5080808@safe.ca> <55383E43.8010505@skarnet.org> <55384A61.5020001@safe.ca> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1429755386 31734 80.91.229.3 (23 Apr 2015 02:16:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 02:16:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7487-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 04:16:14 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 1Yl6gW-0007t1-HE for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 04:16:12 +0200 Original-Received: (qmail 20477 invoked by uid 550); 23 Apr 2015 02:15:20 -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 20423 invoked from network); 23 Apr 2015 02:15:19 -0000 Content-Disposition: inline In-Reply-To: <55384A61.5020001@safe.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7474 Archived-At: On Wed, Apr 22, 2015 at 09:26:57PM -0400, Jean-Marc Pigeon wrote: > > I think the only safe conclusion is that the application is > > incorrect and should ensure that setenv() is never called with a > > NULL value. > > > Checked glibc, My understanding, it set something as > "name=" > in the environment, so the variable is present but > value is "empty"i (top application to decide what to do). > uclibc does something similar (as far I can tell looking > at source code).. > > > The application is not careful enough, but not incorrect as such. It's definitely incorrect. It's doing something that invokes undefined behavior. > Note: we may have tons of applications with the same problem. > if we keep musl setenv like that, musl will be seen as quite unreliable. No, actually glibc is fixing this bug (maybe they already did). See the thread beginning here: https://sourceware.org/ml/libc-alpha/2015-03/threads.html#00449 My understanding is that glibc is planning to do, or already does in the latest version, exactly what musl is doing. > If this situation is indeed UB, there is 2 options for musl: > 1) Swallow the problem nicely... as glibc and uclibc does. > 2) Report an error.. EINVAL? (and document it in manual) > > Crashing at "libc" level is not an option. I can see how it might seem like that at first, but crashing is actually the best possible behavior. Options 1 and 2 cover up a potentially serious bug -- it's not clear what the application was trying to do, most likely nobody even thought about what they were trying to do, and even if they did have something in mind it's not reliable or portable. The glibc wiki has some text taken from text I wrote on the topic (copied from a stack overflow answer I gave) here: https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointers Specifically it covers why returning an error is not a good idea. Rich