From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10327 invoked by alias); 31 May 2013 20:24:03 -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 10300 invoked by uid 89); 31 May 2013 20:24:01 -0000 X-Spam-SWARE-Status: No, score=-6.7 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; Fri, 31 May 2013 20:24:01 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4VKNxeX012810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 16:23:59 -0400 Received: from barimba (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4VKNvUa003184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 16:23:58 -0400 From: Tom Tromey To: Pedro Alves Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: RFC: introduce scoped cleanups References: <87li7ohtiu.fsf@fleche.redhat.com> <87ppw8qlgl.fsf@fleche.redhat.com> <20130531061135.GA12363@adacore.com> <87obbrp2hg.fsf@fleche.redhat.com> <51A8CC81.9070509@redhat.com> Date: Fri, 31 May 2013 20:24:00 -0000 In-Reply-To: <51A8CC81.9070509@redhat.com> (Pedro Alves's message of "Fri, 31 May 2013 17:14:57 +0100") Message-ID: <8738t2q4o2.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/msg01118.txt.bz2 Pedro> Seeing Tom's scope cleanups were already stack based and most of Pedro> the way there, made me feel that it'd be a pity to be able to Pedro> have stack-based cleanups, but then as soon as you need a real Pedro> cleanup that does actual cleanup (as opposed to null_cleanup), Pedro> you still need to get back to install a heap cleanup anyway. My one concern about this code is that, if a stack cleanup should be leaked, then any future cleanup operation will refer to invalid memory. Right now, cleanup failures like this are a memory leak with the possibility of wrong behavior -- but the new way seems more directly fatal. Another option would be to allocate cleanups on an obstack. This would often be efficient and would avoid the above problem. This approach would either have to still leave the special scoped cleanup on the stack, at least when compiling with GCC (and perhaps only if in "development=true" mode); or we would need to come up with some extra hack to make this work properly with obstack allocation. Tom