From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21618 invoked by alias); 29 Jun 2007 18:33:04 -0000 Received: (qmail 21609 invoked by uid 22791); 29 Jun 2007 18:33:04 -0000 X-Spam-Check-By: sourceware.org Received: from b.mail.sonic.net (HELO b.mail.sonic.net) (64.142.19.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Jun 2007 18:33:01 +0000 Received: from snyder (209-204-172-156.dsl.dynamic.sonic.net [209.204.172.156]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id l5TIWtsl016380; Fri, 29 Jun 2007 11:32:56 -0700 Message-ID: <000f01c7ba7b$f2e3af20$677ba8c0@sonic.net> Reply-To: "Michael Snyder" From: "Michael Snyder" To: "Daniel Jacobowitz" Cc: References: <5515.12.7.175.2.1183077423.squirrel@webmail.sonic.net> <20070629004328.GA18113@caradoc.them.org> <9780.12.7.175.2.1183078961.squirrel@webmail.sonic.net> <20070629113703.GB13561@caradoc.them.org> Subject: Re: [OB] pointer ref, m2-typeprint.c Date: Fri, 29 Jun 2007 18:49:00 -0000 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 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/msg00532.txt.bz2 ----- Original Message ----- From: "Daniel Jacobowitz" To: Cc: Sent: Friday, June 29, 2007 4:37 AM Subject: Re: [OB] pointer ref, m2-typeprint.c > On Thu, Jun 28, 2007 at 06:02:41PM -0700, msnyder@sonic.net wrote: > > > If the second line I quoted could crash, the first > > > line definitely will; so if TYPE can really be NULL here, we should > > > fix it properly (instead of this change, which removes the helpful > > > notice that something is wrong :-). > > > > Nooooo... I don't think my change removes any notice. > > Take another look, please? > > Sorry, I meant a notice from Coverity's tools. The problem is that it > knows TYPE_CODE is a dereference (that's a locally derivable > conclusion within this file) but as far as I can tell it doesn't know > that CHECK_TYPEDEF will always dereference its argument (it will). > So now it's not going to complain, but if there was a problem, > there still is. I agree. It would be pretty simple to make CHECK_TYPEDEF safe, and I think I would rather do that than go hunt down every place that calls it. What do you think? Should I add that to this patch? It would add a "not equal to null" test to every call to CHECK_TYPEDEF, of which there are many, but on today's hardware the cost should be less than negligable...