Re: [patch] some mindless additions of BLOCK_ macros

[David Carlton <carlton at math dot stanford dot edu>]

On Wed, 23 Oct 2002 19:04:04 -0400, Andrew Cagney <ac131313@redhat.com> 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