From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22838 invoked by alias); 28 Jun 2007 23:04:34 -0000 Received: (qmail 22830 invoked by uid 22791); 28 Jun 2007 23:04:33 -0000 X-Spam-Check-By: sourceware.org Received: from a.mail.sonic.net (HELO a.mail.sonic.net) (64.142.16.245) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 28 Jun 2007 23:04:31 +0000 Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l5SN4TkT003231; Thu, 28 Jun 2007 16:04:29 -0700 Received: from 12.7.175.2 (SquirrelMail authenticated user msnyder) by webmail.sonic.net with HTTP; Thu, 28 Jun 2007 16:04:29 -0700 (PDT) Message-ID: <10837.12.7.175.2.1183071869.squirrel@webmail.sonic.net> In-Reply-To: <20070628224250.GB12578@caradoc.them.org> References: <13902.12.7.175.2.1183067383.squirrel@webmail.sonic.net> <20070628215829.GA10350@caradoc.them.org> <6989.12.7.175.2.1183069038.squirrel@webmail.sonic.net> <20070628224250.GB12578@caradoc.them.org> Date: Thu, 28 Jun 2007 23:06:00 -0000 Subject: Re: [OB] cli/cli-script.c, null ptr guard From: msnyder@sonic.net To: msnyder@sonic.net, gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00508.txt.bz2 > On Thu, Jun 28, 2007 at 03:17:18PM -0700, msnyder@sonic.net wrote: >> > No, I don't think this is obvious. What does it mean to have a null >> > string here and how can it happen? I'm pretty sure it can't, and the >> > if check is just clutter. >> >> The reasoning is that, since we checked it for NULL in the >> first statement of the function, we must believe that the >> possibility exists for it to be NULL. > > Right. So, is it a sensible check? Or should it be removed, or > should the condition for the error be simplified? Well, it either makes sense to check it for null, or it doesn't. If the new test is redundant, so is the old one. Whoever wrote it in the first place seemed to think it was worth checking. This is called from a number of places, but they are all local to the module. Ultimately the argument comes from the command parser. It's one of those typical (char *args, int from_tty) things. I've never been sure whether those were guaranteed to be non-null, or not.