From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4922 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: asctime(0) Segmentation fault Date: Sat, 19 Apr 2014 21:59:12 -0400 Message-ID: <20140420015912.GU26358@brightrain.aerifal.cx> References: <20140420014339.GA12324@port70.net> 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 1397959175 25906 80.91.229.3 (20 Apr 2014 01:59:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2014 01:59:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4926-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 20 03:59:27 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wbh2U-0004GD-Fw for gllmg-musl@plane.gmane.org; Sun, 20 Apr 2014 03:59:26 +0200 Original-Received: (qmail 20340 invoked by uid 550); 20 Apr 2014 01:59:25 -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 20328 invoked from network); 20 Apr 2014 01:59:25 -0000 Content-Disposition: inline In-Reply-To: <20140420014339.GA12324@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4922 Archived-At: On Sun, Apr 20, 2014 at 03:43:39AM +0200, Szabolcs Nagy wrote: > * John Mudd [2014-04-19 18:46:42 -0400]: > > It looks like asctime(0) should return 0 instead of Segmentation fault. > > no To elaborate, 0 is not a valid pointer to struct tm, so the behavior is undefined. The preferred response to undefined behavior is always an immediate crash. In some cases that's not possible, or at least would involve significant additional effort to achieve. But here, like many places, it's the automatic natural behavior. It's definitely not acceptable to bury undefined behavior that would otherwise be caught by special-casing it with code to ignore it. The proposed behavior (returning a null string pointer) would propagate the error further and it would be more work to determine the origin of the error (or it might not be detected at all). > what was the python test failure? > > my guess is that they pass something to asctime without checking for 0 > > that something being 0 may be a musl bug or a python test framework bug Indeed, this would be interesting to know, as it might reveal a real bug (either a bug in musl we need to fix, or a portability bug in python that's affecting its use on musl). Rich