From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29593 invoked by alias); 5 Feb 2003 03:06:30 -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 29572 invoked from network); 5 Feb 2003 03:06:30 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 5 Feb 2003 03:06:30 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18gHmP-00019f-00 for ; Tue, 04 Feb 2003 23:07:25 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18gFtP-0006cQ-00 for ; Tue, 04 Feb 2003 22:06:31 -0500 Date: Wed, 05 Feb 2003 03:06:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [rfa] replace SYMBOL_SOURCE_NAME by SYMBOL_PRINT_NAME Message-ID: <20030205030631.GA25425@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00164.txt.bz2 On Tue, Feb 04, 2003 at 06:00:34PM -0800, David Carlton wrote: > Right now, GDB has a macro called SYMBOL_SOURCE_NAME that gives you > the demangled name of a symbol if 'demangle' is true, and the mangled > name if 'demangle' is false. > > It's mostly used in output routines; its use there is entirely > appropriate. It's sometimes used for internal purposes instead; its > use there is not nearly as appropriate. (E.g. what if you sort or > hash a table when demangle is false and then look up something in a > table when demangle is true?) The internal uses should all be > replaced by a different macro (to appear in a future use) which > doesn't depend on the value of demangle. > > Here's a patch to begin dealing with the issue. It renames > SYMBOL_SOURCE_NAME to SYMBOL_PRINT_NAME and adds a comment making it > clear that it's only suitable for output. It changes all occurrences > of the macro in a completely mechanical way; in a later patch, I'll go > through all the occurrences to see if they look appropriate or not. > > The only part of the patch worth looking at is the symtab.h part, > which I've listed first; the rest should (I hope!) be purely > mechanical. > > Tested on i686-pc-linux-gnu/GCC3.1/DWARF-2, and should be obviously > correct if you accept the underlying idea (and if I didn't screw up > with my keyboard macros in Emacs). OK to commit? I still don't understand why you want to rename it. Why not just clarify the comment? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer