From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 9 21:18:35 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F2416A4CE; Wed, 9 Mar 2005 21:18:35 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBBB743D41; Wed, 9 Mar 2005 21:18:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j29LIVA6005603; Thu, 10 Mar 2005 08:18:31 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j29LISS5015426; Thu, 10 Mar 2005 08:18:30 +1100 Date: Thu, 10 Mar 2005 08:18:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dan Allen In-Reply-To: <16e5d2d5e1683cd7fd3f4c9e8a3da2e3@airwired.net> Message-ID: <20050310080804.S48960@delplex.bde.org> References: <200503091418.j29EIP4e033478@freefall.freebsd.org> <16e5d2d5e1683cd7fd3f4c9e8a3da2e3@airwired.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-bugs@FreeBSD.org cc: Gleb Smirnoff Subject: Re: kern/78256: strstr could be more robust X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 21:18:35 -0000 On Wed, 9 Mar 2005, Dan Allen wrote: > On Mar 9, 2005, at 7:18 AM, Gleb Smirnoff wrote: >> Not a bug, sorry. See also bin/52691. > Why are you so reluctant to add one test to improve robustness? Since it is > not specified one way or the other in the standard, it will not break > compatibility with the standard. So it is not a bug technically - you still > could with a single line of C code improve the robustness of the system. Not > doing so seems shortsighted. Adding the test would unimprove robustness (except on systems that don't trap on null pointers -- then a test, followed by a call to abort() or signal(), would be needed to give the same behaviour as a null pointer trap). Aborting a program immediately when undefined behaviour in it is detected improves robustness by limiting the undefined behaviour to just halting the program and possibly generating a core dump, and by making the bug obvious and easy to debug so that it gets fixed. Bruce