From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7481 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: setenv if value=NULL, what say standard? Bug? Date: Thu, 23 Apr 2015 11:23:29 +0200 Message-ID: <5538BA11.90402@skarnet.org> 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1429781035 25811 80.91.229.3 (23 Apr 2015 09:23:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 09:23:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7494-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 11:23:40 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 1YlDMB-0008LN-Fq for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 11:23:39 +0200 Original-Received: (qmail 9482 invoked by uid 550); 23 Apr 2015 09:23:36 -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 9439 invoked from network); 23 Apr 2015 09:23:35 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <5538740E.1030306@safe.ca> Xref: news.gmane.org gmane.linux.lib.musl.general:7481 Archived-At: On 23/04/2015 06:24, Jean-Marc Pigeon wrote: > 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... And why do you think the problem exists in the first place ? Because other libcs were defensive and failed to fail early, so the bug was never discovered until now. Your application is not working perfectly right - it is buggy, and it *should* fail. musl is giving developers a gift that other libcs do not: it helps them debug. > (so someone will propose to set a cron to automatically restart this > unreliable daemon, hmmm...) You want to be defensive, well, yeah, this is the place to be defensive. Until the bug is found and fixed, at least the daemon is kind of providing service. Raphael says this behaviour is wrong for the same reason that silently failing is wrong, but I disagree. First, restarting crashing daemons is not silent at all, a crash is always a loud warning and can hardly be ignored; and second, restarting a process is not continuing it. A process can always be restarted from a clean state and work in a predictable way until it trips the bug again, whereas silently ignoring UB makes the process unpredictable for the rest of its lifetime. > 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. What "trouble" status do you return when a function dereferences a NULL pointer ? This is exactly what's happening here. Passing NULL to setenv is as incorrect as dereferencing NULL, and should result in the same behaviour. > 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). The language you want is Javascript, not C. > 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". And this is why musl is so much better. If glibc and uclibc devs hadn't been so complacent, the bug wouldn't have lived for so long. > Crashing is not an option for code pertaining to musl/libc layer. It definitely is. You don't want your program to crash ? Don't invoke UB. If you want to be "safe", you can ignore SIGSEGV at the start of all your applications - it will be the exact same thing as what you are asking. Your daemons will live longer, I guarantee it. > (:-} why bother to return an error, just crash for all > problems in open, close, write, etc. just bringing the crashing > concept to the extreme :-}). Straw man. You know as well as we do the difference between a programming error and a run-time error. > 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) And mine is that it is. We're evens, now please let's stop bringing up anecdotal evidence. -- Laurent