From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12288 invoked by alias); 7 May 2013 14:40:37 -0000 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 Received: (qmail 12275 invoked by uid 89); 7 May 2013 14:40:37 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 14:40:36 +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 r47EeYON003554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 10:40:34 -0400 Received: from barimba (ovpn-113-163.phx2.redhat.com [10.3.113.163]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r47EeWqe028842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 7 May 2013 10:40:33 -0400 From: Tom Tromey To: Joel Brobecker Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH References: <20130501165750.GA453@host2.jankratochvil.net> <87obcoyot3.fsf@fleche.redhat.com> <20130507062305.GH5278@adacore.com> Date: Tue, 07 May 2013 14:40:00 -0000 In-Reply-To: <20130507062305.GH5278@adacore.com> (Joel Brobecker's message of "Tue, 7 May 2013 10:23:05 +0400") Message-ID: <87ip2uvonz.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-05/txt/msg00231.txt.bz2 Joel> Should we consider changing it into an internal_warning? I think that is fine as long as it still makes tests fail. Tom> I think it would be possible to automate adding this declaration in Tom> all needed spots. I'm curious what you think about it. Joel> I'm certainly curious about the suggestion. How would the current Joel> code be adapted to make this work? Well, first a manual patch both to define this macro appropriately and to add whatever supporting functions are needed. Then, modify the cleanup checker to add this declaration to any function it thinks could use it. The cleanup checker already has some code, written in a more optimistic time, to try to determine whether a function could be converted to "RAII style". It could be adapted to insert the macro use at the right spot. Then, rebuild and fix whatever bugs were introduced. Finally, update our patch review guidelines so we know to look for this macro in ordinary cleanup-using functions. Alternatively I think we could probably change all the code to be cleanup-checker-clean. I'll try to prep that series soon to see what people think. I think it actually less work. Tom