From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13390 invoked by alias); 27 Jan 2003 22:09:59 -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 13322 invoked from network); 27 Jan 2003 22:09:59 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 27 Jan 2003 22:09:59 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h0RM9pu05752; Mon, 27 Jan 2003 14:09:51 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: 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> From: David Carlton Date: Mon, 27 Jan 2003 22:09:00 -0000 In-Reply-To: <3E35A2EA.1080906@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00742.txt.bz2 On Mon, 27 Jan 2003 16:21:46 -0500, Andrew Cagney said: > The more `char *' -> `const char *' stomping, the better. I spent some time on my branch trying to make this change quite broadly (basically, turning name members of various structs into const char *'s and dealing with the fallout). It ran into some serious problems, though; I seem to recall that, ultimately, they came down to decode_line_1 taking a char ** instead of a const char **. And decode_line_1 really does (temporarily) change the characters that are pointed to, unfortunately. So if we ever want to get this right across the board, fixing decode_line_1 is probably the main outstanding task. 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'... David Carlton carlton@math.stanford.edu