From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26554 invoked by alias); 7 Nov 2011 15:39:03 -0000 Received: (qmail 26541 invoked by uid 22791); 7 Nov 2011 15:39:02 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 15:38:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7Fcml5011137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 10:38:48 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA7FclS7020609; Mon, 7 Nov 2011 10:38:47 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pA7Fcj6d011551; Mon, 7 Nov 2011 10:38:46 -0500 From: Tom Tromey To: Petr =?utf-8?Q?Hluz=C3=ADn?= Cc: paawan oza , "gdb-patches\@sourceware.org" , chandra krishnappa Subject: Re: [PATCH] arm reversible : References: <998639.46560.qm@web112516.mail.gq1.yahoo.com> <321260.58442.qm@web112504.mail.gq1.yahoo.com> <1316327455.23344.YahooMailNeo@web112509.mail.gq1.yahoo.com> <1316404058.27177.YahooMailNeo@web112502.mail.gq1.yahoo.com> <1318650316.91503.YahooMailNeo@web112508.mail.gq1.yahoo.com> Date: Mon, 07 Nov 2011 15:39:00 -0000 In-Reply-To: ("Petr \=\?utf-8\?Q\?Hluz\=C3\=ADn\=22's\?\= message of "Sat, 5 Nov 2011 18:34:41 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-11/txt/msg00153.txt.bz2 >>>>> "Petr" =3D=3D Petr Hluz=C3=ADn writes: Petr> How strong is the "can't happen" requirement? Is programmer required Petr> to prove the assertion cannot be triggered? The difficulty in general Petr> case would be equivalent to proving a code is bug-free - i.e. it is Petr> impossible. At my job we try to verify an assumption until we have a Petr> sort-of-proof or the search becomes difficult and no clue/indication Petr> to the contrary has been found yet. Petr> I am asking because GDB code contains surprisingly few assertions. I don't think there is a hard-and-fast rule in gdb. I am not completely sure though. I think in gdb it is best to error instead of assert if there is any doubt. That's because I think when people turn to gdb they are already a bit frustrated, and then if gdb itself fails, this is extremely irritating. That's certainly been the case for me in the past. I realize you can sort of recover from internal_error (and hence assertions). But my impression is that internal_error is treated like "not an exception-thrower" in gdb, leading to cleanup problems and the like. Petr> Anyway, the patch had used assertions correctly because expression Petr> `bits (X, 21, 24)' yields value in range 0..15 for any value of X - no Petr> matter how bogus X value. Yes, all 2^32 values map to 0..15. The Petr> assertions satisfy the guideline. (This is not even the hard-to-prove Petr> case I was speculating above.) Yeah, my review was wrong here. Tom