From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20527 invoked by alias); 4 Jan 2006 12:17:00 -0000 Received: (qmail 20519 invoked by uid 22791); 4 Jan 2006 12:16:59 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 12:16:57 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-04.spheriq.net with ESMTP id k04CGsD6024731 for ; Wed, 4 Jan 2006 12:16:54 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id k04CGpgG028293 for ; Wed, 4 Jan 2006 12:16:53 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id k04CGoBn020634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 4 Jan 2006 12:16:51 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E9EC0DACF; Wed, 4 Jan 2006 12:14:55 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 86180473AB; Wed, 4 Jan 2006 12:18:12 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3282775999; Wed, 4 Jan 2006 12:18:12 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 94A79473A2; Wed, 4 Jan 2006 12:18:11 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHC48338 (AUTH stubbsa); Wed, 4 Jan 2006 12:14:48 GMT Message-ID: <43BBBBC3.1010201@st.com> Date: Wed, 04 Jan 2006 12:17:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [RFC] Alternate approach to keeping convenience variables References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> In-Reply-To: <20051209205923.GA21331@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00038.txt.bz2 Hi, I'm back! Thanks for this work. I do not follow exactly how it works (I suppose that's the difference between somebody who knows GDB and somebody who does not) but it does appear to solve the problem at hand. One point though - why is it ok to leak the memory? This seems like bad practice to me - I mean, types can be arbitrarily large and, even if they are typically small, the variables may be rewritten many many times (particularly by scripts with loops). Are you saying that they will be actually leaked or just left for some sort of garbage collection? Otherwise excellent - just what I need. I'll be very happy when this goes in. Thanks again Andrew Stubbs