From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from acme.spoerlein.net (acme.spoerlein.net [88.198.49.12])
	by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id r4IJQsaA027490
	for <tech@mdocml.bsd.lv>; Sat, 18 May 2013 15:26:54 -0400 (EDT)
Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1])
	by acme.spoerlein.net (8.14.7/8.14.6) with ESMTP id r4IJQr57033332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 18 May 2013 21:26:53 +0200 (CEST)
	(envelope-from uqs@spoerlein.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net;
	s=dkim200908; t=1368905214;
	bh=VBan5V1mceLG0Mzu9ih6Xgyfabx60M8pMhCU/15wElc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=Nv8s1E+3XsCHOEtCS+VlQx2R7hojBFGYqUPZ7kw1jpZzv8gsbLjTk0/owDst0DOzA
	 2zZgPPyJkCUn/q0kD+TVWFG+hbpdVKBF4wx58OiQfnuXFf51Uw077lzxNS9OVYYUuN
	 VaGiYfHhExDjDIvUXY6nZzTucbchbxEUpEFQzQIw=
Date: Sat, 18 May 2013 21:26:53 +0200
From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net>
To: Ingo Schwarze <schwarze@usta.de>
Cc: tech@mdocml.bsd.lv
Subject: Re: [patch] avoid possible null pointer dereference
Message-ID: <20130518192653.GH2055@acme.spoerlein.net>
References: <20130517013739.GZ2055@acme.spoerlein.net>
 <20130518175435.GB13985@iris.usta.de>
X-Mailinglist: mdocml-tech
Reply-To: tech@mdocml.bsd.lv
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20130518175435.GB13985@iris.usta.de>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Sat, 2013-05-18 at 19:54:35 +0200, Ingo Schwarze wrote:
> Hi Ulrich,
> 
> Ulrich Spörlein wrote on Fri, May 17, 2013 at 03:37:39AM +0200:
> 
> > termp_xx_pre() will call term_word() with NULL when the switch case
> > falls through to the default case.
> 
> Actually, that cannot happen because termp_xx_pre() will not be called
> for macros it is not intended to handle.
> 
> Still, it's arguably a cosmetical issue.  The code looks like the default
> case would be legitimate, which it is not.
> 
> > There are several ways to avoid the segfault, not sure this is the
> > best one.
> 
> No, it isn't, because that merely substitutes one uncontrolled failure
> mode by another one that's arguably even harder to debug, should it
> ever occur (after incorrect code changes elsewhere).
> 
> Instead, i committed a change to bsd.lv and openbsd.org using abort(3).

Thanks! I figured that it was not the best fix, but I don't know the API
"contracts" within mdocml.

There are a couple more issues that Coverity Scan thinks exists, but I
need to understand those better first.

Cheers,
Uli
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv