From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7477 Path: news.gmane.org!not-for-mail From: Raphael Cohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: setenv if value=NULL, what say standard? Bug? Date: Thu, 23 Apr 2015 06:08:27 +0100 Message-ID: References: <553837F1.5080808@safe.ca> <55383E43.8010505@skarnet.org> <55384A61.5020001@safe.ca> <20150423021507.GG6817@brightrain.aerifal.cx> <5538740E.1030306@safe.ca> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01182fbc18eb0905145d4520 X-Trace: ger.gmane.org 1429765735 13795 80.91.229.3 (23 Apr 2015 05:08:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 05:08:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7490-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 07:08:42 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 1Yl9NR-00064q-Uy for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 07:08:42 +0200 Original-Received: (qmail 21621 invoked by uid 550); 23 Apr 2015 05:08:39 -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 21597 invoked from network); 23 Apr 2015 05:08:39 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=leYLlm6WrNDT19sr398N2ypkQZGaLmyLwZsr7xY6cOo=; b=fErApaZ/r0WUHdf0sfqtePbjdtRYxMb+wmPYXn7X395LhcT7mtstDUu5HvCd8qQLKO 1wEZJpH1UVGIJ5gBdbH76hBARXi53rpyWKohSoQaoFio3MSNnEfb8MsWanK4R9ZklKll 4IXhrJSUIKU4W6MM6whKAqJ2omvfGa2NyxmnSunJq27QzNCNBza/JjXplQzlZ737lwn7 zNh7iVaAXYIMlurOq6IV+x2vJH9rbOdfsDuRAOL49eEAzcTfYCWPC0WrG/Q4zefzuKmz dVgk3qXmZBJlc1FNpoUtXV3vOR2hOEaQtDd62FY7j0eISjgMFY368W10ypIM4yJZraI9 Oi2A== X-Gm-Message-State: ALoCoQmoHGz5HH5ta5ej/3XGnRe6duuvME6Ap1ZY0YgIy8dkUxGFSMtfCSnU1K3MZe+e9jTc7GSL X-Received: by 10.60.103.133 with SMTP id fw5mr859800oeb.17.1429765707320; Wed, 22 Apr 2015 22:08:27 -0700 (PDT) X-Originating-IP: [90.155.92.120] In-Reply-To: <5538740E.1030306@safe.ca> Xref: news.gmane.org gmane.linux.lib.musl.general:7477 Archived-At: --089e01182fbc18eb0905145d4520 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fail fast, fail early is always the right thing to do. I've seen far too much code in my career that tries to 'carry on' after encountering an unexpected condition. It's always the wrong thing to do, even for nuclear power plants. Once you're in UB land, the rest of your reasoning about your code is invalid. The best you can do is gracefully shutdown and capture as much diagnostic info as is feasible. Expecting musl to 'cover up' should be seen the same as in the real world - cover ups just make the problem worse. Unexpected is not the same as expected but unpleasant to deal with eg failures to open(). And so hence the arguments about checked and unchecked exceptions and so on. Oh and auto restarting daemons is almost always wrong. For exactly the same reasoning - and frequently leads to data corruption. On 23 Apr 2015 05:25, "Jean-Marc Pigeon" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/22/2015 10:15 PM, Rich Felker wrote: > > 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=3D" 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 > I strongly disagree, crashing is not an option for a tools as > musl/libc. > > Think about this, you write an application working perfectly right, > but 1 in 1000000 you reach something not trapped by low level and > once in while the application (in production for month) just stop > to work because "unexpected" within musl... > (so someone will propose to set a cron to automatically restart this > unreliable daemon, hmmm...) > > Far better to return "trouble" status, then it is to the application > to decide what must be done in context, as ignore, override, bypass, > crash, etc. > > A sensible policy in case of UB would be for such low level code to > swallow the problem, (protect the hardware and keep the program > running as much as possible). > > > 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: > > As reported, the crashing application is hwclock, (util-linux-2.26), > this a kind of code in the field for a very very long time, so the > library (glibc and old libc) used for linux over the years defined an > expected behavior to this "UB". > As other occurrence of this could be present too in other > program/application, crashing would make a bench of applications > to be running hazard (you can have all kind situation with > env variables, near unpredictable). > > Something worry me in comments I have seen in the proposed URL, > IMHO purpose of musl/glibc is not to "find bugs by crashing", its > purpose is to be a code "clean, lean, reliable, predictable" (as said > above, "Protect the hardware, report problem, lets the above layer > application decide what to do in case of problem"). > > Crashing is not an option for code pertaining to musl/libc layer. > > (:-} why bother to return an error, just crash for all > problems in open, close, write, etc. just bringing the crashing > concept to the extreme :-}). > > > > > > > https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointer= s > > > > Specifically it covers why returning an error is not a good idea. > My experience (for a long time now) about writing complex daemon > running for months/year, it is not that straightforward (may > be for a simple application it is) > > > > > Rich > > > > > - -- > > A bient=C3=B4t > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jean-Marc Pigeon E-Mail: jmp@safe.ca > SAFE Inc. Phone: (514) 493-4280 > Clement, 'a kiss solution' to get rid of SPAM (at last) > Clement' Home base <"http://www.clement.safe.ca"> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJVOHQOAAoJEAtgwJ4bBQU5bCUP/jxt74112bqFat0+CvFpqNG8 > sCEYEIpRcKIB7wWRLwQXQTQ0M82oUzo6bmpYtgorcwJWh5NIo/dFm2FvDW+/uiTs > dtutt45jJN7tsq4BhE/z/jyD44vrVqYZ+gJXf3MFPWeTFx4Kd7aCq3dCDvvoT9lk > Mp9KiiSY+WXfwE/a8CAiw6D+Ma2/iN4zTD1fUekXcZDgu0iMsieeF5uhZNT/L+62 > U8K2VdOoR1H731v3GzKFUiesPTiPNbASg0MDfKyYe5kCZMkijbHIx7fGb/VID6dv > 01u3bNA8yTfj51MplGv3ddgAzYcOMBMrQ6IXBK4hQPm4wuGp3ELr6IiTepUfkc3y > WYlNHCFqpgMthj2+nsMllwK+uZcbW36+QlYQ4FCuAMaqOjpA+Yr6qmoiOl5HFSMA > FoqarDkUeH3jYWYBFq8aUFQdD8Esyj3mKXAc/Bw45vWGkBykTyJXMYGVh4idukFQ > dkiYTM5rOB3H55dkjB9EnojAX+w0+VG+0H5xtb8fybtQYEr7SbsRO5fhTbmTr/1P > Q6ojm8fhkoRT0JXC+94htj5rT/87QerVIu06YcozqOsqCKBm7HBkokkMTMtWofJ4 > sznm9/OtNqbYYTSdDQ7AVn1x0K8ycz5Aw302NOWd5NuSEPal+GuWP2mewhydlXAj > 2+W/ox353kVOSWf0t2Ql > =3DR+I2 > -----END PGP SIGNATURE----- > > --089e01182fbc18eb0905145d4520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Fail fast, fail early is always the right thing to do. I'= ;ve seen far too much code in my career that tries to 'carry on' af= ter encountering an unexpected condition. It's always the wrong thing t= o do, even for nuclear power plants. Once you're in UB land, the rest o= f your reasoning about your code is invalid. The best you can do is gracefu= lly shutdown and capture as much diagnostic info as is feasible. Expecting = musl to 'cover up' should be seen the same as in the real world - c= over ups just make the problem worse.

Unexpected is not the same as expected but unpleasant to dea= l with eg failures to open(). And so hence the arguments about checked and = unchecked exceptions and so on.

Oh and auto restarting daemons is almost always wrong. For e= xactly the same reasoning - and frequently leads to data corruption.

On 23 Apr 2015 05:25, "Jean-Marc Pigeon&quo= t; <jmp@safe.ca> wrote:
-----BEGIN PGP SIGNED MESSAGE-= ----
Hash: SHA1

On 04/22/2015 10:15 PM, Rich Felker wrote:
> 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=3D= " in
>> the environment, so the variable is present but value is "emp= ty"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/thread= s.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<= br> >> 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
I strongly disagree, crashing is not an option for a tools as
musl/libc.

Think about this, you write an application working perfectly right,
but 1 in 1000000 you reach something not trapped by low level and
once in while the application (in production for month) just stop
to work because "unexpected" within musl...
(so someone will propose to set a cron to automatically restart this
unreliable daemon, hmmm...)

Far better to return "trouble" status, then it is to the applicat= ion
to decide what must be done in context, as ignore, override, bypass,
crash, etc.

A sensible policy in case of UB would be for such low level code to
swallow the problem, (protect the hardware and keep the program
running as much as possible).

> 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:

As reported, the crashing application is hwclock, (util-linux-2.26),
this a kind of code in the field for a very=C2=A0 very long time, so the library (glibc and old libc) used for linux over the years defined an
expected behavior to this "UB".
As other occurrence of this could be present too in other
program/application, crashing would make a bench of applications
to be running hazard (you can have all kind situation with
env variables, near unpredictable).

Something worry me in comments I have seen in the proposed URL,
IMHO purpose of musl/glibc is not to "find bugs by crashing", its=
purpose is to be a code "clean, lean, reliable, predictable" (as = said
above, "Protect the hardware, report problem, lets the above layer
application decide what to do in case of problem").

Crashing is not an option for code pertaining to musl/libc layer.

(:-} why bother to return an error, just crash for all
problems in open, close, write, etc. just bringing the crashing
concept to the extreme :-}).



>
> https://sourceware.org/glibc/wiki/Style_an= d_Conventions#Invalid_pointers
>
>=C2=A0 Specifically it covers why returning an error is not a good idea= .
My experience (for a long time now) about writing complex daemon
running for months/year, it is not that straightforward (may
be for a simple application it is)

>
> Rich
>


- --

A bient=C3=B4t
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Jean-Marc Pigeon=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 E-Mail: jmp@safe.ca=
SAFE Inc.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Phone: (514) 493-4280
=C2=A0 Clement, 'a kiss solution' to get rid of SPAM (at last)
=C2=A0 =C2=A0 =C2=A0Clement' Home base <"http://www.clement.safe.ca">=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJVOHQOAAoJEAtgwJ4bBQU5bCUP/jxt74112bqFat0+CvFpqNG8
sCEYEIpRcKIB7wWRLwQXQTQ0M82oUzo6bmpYtgorcwJWh5NIo/dFm2FvDW+/uiTs
dtutt45jJN7tsq4BhE/z/jyD44vrVqYZ+gJXf3MFPWeTFx4Kd7aCq3dCDvvoT9lk
Mp9KiiSY+WXfwE/a8CAiw6D+Ma2/iN4zTD1fUekXcZDgu0iMsieeF5uhZNT/L+62
U8K2VdOoR1H731v3GzKFUiesPTiPNbASg0MDfKyYe5kCZMkijbHIx7fGb/VID6dv
01u3bNA8yTfj51MplGv3ddgAzYcOMBMrQ6IXBK4hQPm4wuGp3ELr6IiTepUfkc3y
WYlNHCFqpgMthj2+nsMllwK+uZcbW36+QlYQ4FCuAMaqOjpA+Yr6qmoiOl5HFSMA
FoqarDkUeH3jYWYBFq8aUFQdD8Esyj3mKXAc/Bw45vWGkBykTyJXMYGVh4idukFQ
dkiYTM5rOB3H55dkjB9EnojAX+w0+VG+0H5xtb8fybtQYEr7SbsRO5fhTbmTr/1P
Q6ojm8fhkoRT0JXC+94htj5rT/87QerVIu06YcozqOsqCKBm7HBkokkMTMtWofJ4
sznm9/OtNqbYYTSdDQ7AVn1x0K8ycz5Aw302NOWd5NuSEPal+GuWP2mewhydlXAj
2+W/ox353kVOSWf0t2Ql
=3DR+I2
-----END PGP SIGNATURE-----

--089e01182fbc18eb0905145d4520--