From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23378 invoked by alias); 27 Jan 2003 23:17:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23370 invoked from network); 27 Jan 2003 23:17:23 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by 172.16.49.205 with SMTP; 27 Jan 2003 23:17:23 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8A1EE406E; Mon, 27 Jan 2003 18:17:15 -0500 (EST) Message-ID: <3E35BDFB.7020306@redhat.com> Date: Mon, 27 Jan 2003 23:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton Cc: Andreas Schwab , Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFC: Demangle partial symbols and save memory too References: <20030126222808.GA18132@nevyn.them.org> <20030127190109.GA11294@nevyn.them.org> <3E35A2EA.1080906@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00747.txt.bz2 > On Mon, 27 Jan 2003 23:17:55 +0100, Andreas Schwab said: > >> David Carlton writes: > > >>> I also toyed with trying to replace 'struct XXX *' with 'const >>> struct XXX *' wherever appropriate. That one's harder, though, >>> because there are structures in GDB where values are computed >>> lazily and cached: so not only are there functions that are >>> logically const but not actually const, but I also worried that >>> making too many declarations const now would inhibit such caching >>> in the future. Maybe in a couple of years we can switch GDB over >>> to C++ instead of C and use 'mutable'... > > >> Even in C casting away const is OK as long as the object isn't >> read-only in the first place. You just have to be careful to make >> sure this is not violated. > > > That's a good point. I don't like casts, of course, but in this > particular situation my dislike of casts might be trumped by my liking > of const when logically appropriate. I'd rather not see such casts. It is easier to recommend no casts then to recommend no casts `but'. The current objective for const is just with strings - getting GDB past -Wwriteable-strings so that we know that all constant strings can be moved to the text segment. Andrew