From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15072 invoked by alias); 23 Oct 2002 23:19:12 -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 15065 invoked from network); 23 Oct 2002 23:19:11 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 23 Oct 2002 23:19:11 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9NNJ4I20401; Wed, 23 Oct 2002 16:19:05 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] some mindless additions of BLOCK_ macros References: <3DB72AE4.1040908@redhat.com> From: David Carlton Date: Wed, 23 Oct 2002 16:19:00 -0000 In-Reply-To: <3DB72AE4.1040908@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: 2002-10/txt/msg00492.txt.bz2 On Wed, 23 Oct 2002 19:04:04 -0400, Andrew Cagney said: >> I recently noticed that the BLOCK_ macros weren't used everywhere >> they could be. I know Andrew doesn't like macros, but given that >> these ones are used almost everywhere, they might as well be used >> everywhere. > Yep. > It's more that I like opaque types - it is all about `control' - > with an opaque type it simply isn't possible to sneak in [old] code > that grubs around in the internals. You could consider block.[hc]? Opaque types are good, no question about that. Some of the macros in symtab.h are also places where polymorphism would be helpful (c.f. the recent INIT_DEMANGLED_NAME stuff), but I don't think people would be too open to starting to rewrite parts of GDB in C++ just yet... Actually, the reason why I discovered some of these places was because I did create block.h on carlton_dictionary-branch: I got sick of having to recompile most of GDB every time I tried to fiddle with struct block, so I split out struct block and struct blockvector. (But I haven't created block.c, largely because there's only two function prototypes that seem to clearly belong in block.h.) I posted an RFC for splitting up symtab.h a few weeks ago, which got a tepid response; if I decide that I like having a separate block.h, I'll probably test the waters again in a month or so and see if I can get approval for it on the mainline as well. (And maybe eventually split out other parts of symtab.h later; who knows.) >> This patch seems obvious to me; if nobody complains, I'll commit it >> in a day or two. > I think its safe for today. Okay, I'll do it when I have a moment. David Carlton carlton@math.stanford.edu