From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 16:03:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4FB91065692 for ; Tue, 10 Nov 2009 16:03:27 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id C10D68FC15 for ; Tue, 10 Nov 2009 16:03:27 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nAAG3Ro05498; Tue, 10 Nov 2009 08:03:27 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nAAG3R122152; Tue, 10 Nov 2009 08:03:27 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Tue, 10 Nov 2009 08:03:26 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Alexander Best In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Giorgos Keramidas , freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:03:28 -0000 On Tue, 10 Nov 2009, Alexander Best wrote: > ps: would be nice if strcasecmp could protect itself from segfault with one or > both of the args being NULL. I disagree. What do you think it should do instead? Return 0? If it did, would you have found your bug? The same argument could be made for any of the string.h functions, but I don't think it actually holds water. Such checks add overhead, and only provide an illusion of safety. Sure, strcasecmp could avoid causing the segfault itself, but at the cost of letting a broken program continue and possibly cause more damage. It could call abort(), but then you'd just have the same result (program terminates) with a different signal, and doing your check in software rather than letting the MMU hardware do it. It could print a message, but that pollutes the program's output, and 15 seconds debugging the core dump will reveal the problem anyway. Having a library function "protect itself" in this manner is not actually helpful, IMHO. -- Nate Eldredge nate@thatsmathematics.com