From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6424 invoked by alias); 14 Feb 2011 15:29:11 -0000 Received: (qmail 6416 invoked by uid 22791); 14 Feb 2011 15:29:10 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Feb 2011 15:29:06 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id p1EFRfEM023911; Mon, 14 Feb 2011 16:27:41 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id p1EFRc0c022596; Mon, 14 Feb 2011 16:27:38 +0100 (CET) Date: Mon, 14 Feb 2011 16:00:00 -0000 Message-Id: <201102141527.p1EFRc0c022596@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: <201102141519.39403.pedro@codesourcery.com> (message from Pedro Alves on Mon, 14 Feb 2011 15:19:39 +0000) Subject: Re: No longer accept NULL values in value_bits_valid and value_bits_synthetic_pointer References: <201102141156.49457.pedro@codesourcery.com> <201102141158.02189.pedro@codesourcery.com> <201102141450.p1EEoNV6003363@glazunov.sibelius.xs4all.nl> <201102141519.39403.pedro@codesourcery.com> 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: 2011-02/txt/msg00283.txt.bz2 > From: Pedro Alves > Date: Mon, 14 Feb 2011 15:19:39 +0000 > > On Monday 14 February 2011 14:50:23, Mark Kettenis wrote: > > > 2011-02-14 Pedro Alves > > > > > > * value.c (value_bits_valid, value_bits_synthetic_pointer): > > > No longer handle NULL values. > > > > Would it be a good idea to add a gdb_assert() here to check for a NULL pointer? > > I considered it, but then didn't add it. None of the > other value_ functions does that before dereferencing > the value. There aren't many places these functions are > called, and, I still plan on putting an assertion like > that in a few more central places, near the roots of > the val_print & co call chains, which should cover > this as well. Fair enough. Diff looks reasonable to me.