Re: references to uninitialized static const members

[david carlton <carlton at math dot Stanford dot EDU>]

On Tue, 6 Aug 2002 11:59:36 -0700, david carlton <carlton@math.Stanford.EDU> said:

> I'm no C++ expert, but failing to initialize your static const
> members doesn't sound like a very bright idea to me.  Nonetheless,
> it seems to be legal C++ (g++ doesn't complain), so GDB should
> handle it better than it does.  The problem is that, in
> values.c(value_static_field), the symbol returned by lookup_symbol
> has the class LOC_UNRESOLVED; the comment in the code there claims
> that "Anything static that isn't a constant, has an address", but
> that fails in this case.

> I'm including a patch below that tests for LOC_UNRESOLVED and, if so,
> returns NULL.  This seems the best way to handle the situation

I've thought about it a bit more, and I'm not so sure that it's the
best way to handle the situation.  It certainly seems to me to be the
case that value_static_field() should return NULL, but I'm a little
less happy with testing for LOC_UNRESOLVED.

This seems to me to be an instance of a general phenomenon where names
that are declared in one compilation unit might or might not actually
get defined in other compilation units.  In other similar situations
that I've looked at in GDB, lookup_symbol() and
lookup_minimal_symbol() both return NULL; it would be more consistent
to have that be the case here, as well.  I assume that it's considered
a bad idea for symbols whose SYMBOL_CLASS equals LOC_UNRESOLVED to
escape outside of a fairly narrow domain within GDB, so in that case
testing for LOC_UNRESOLVED here probably is a sign that something has
gone wrong somewhere else.

And, in fact, the situation is more specific than I claimed above: it
only happens with uninitialized static const _integral_ members.
Normally, if you have a static member (whether const or not), you have
to initialize it exactly once somewhere within your program; but if
it's also const integral, you're allowed to initialize it in multiple
locations with identical constant-expressions, since its value can
then be calculated at compile time.  I'm not sure exactly why the
combination of uninitialized static const integral member + DWARF-2 is
triggering this; maybe it's a bug in G++, actually, but I should
probably try to understand dwarf2read.c a little better so I can try
to understand how that symbol got added to the symbol table.

If anybody has any tips, I'm all ears.

David Carlton
carlton@math.stanford.edu