Re: RFD - cleaning up C identifier lookup

[Zack Weinberg <zack at codesourcery dot com>]

Geoff Keating <geoffk at geoffk dot org> writes:

> One example I saw was that in a header, the programmer had written
> something like:
>
> static inline int get_foo1 (void) 
> {
>   extern int internal_foo1;
>   return internal_foo1 + FOO1_BIAS;
> }
> ...  (for foo2, foo3, etc., up to maybe foo20, with get & set operations)
> presumably so that 'internal_foo1' would be hidden from the user of the
> header but still getting the benefits of inlining.
>
> In this case, would the list have 20 elements, or just one?  I think
> one would still be OK, but 20 might get bad.  I don't think more than
> one should be needed, since the elements can be (should be) kept out
> of the list when they're no longer in scope.

I'm afraid it would be 20 elements.  The point is to detect and
diagnose a situation like this (which is undefined behavior even if
the second decl is not used - see 6.2.7p2):

static inline int get_foo1 (void)
{
  extern int internal_foo1;
  return internal_foo1 + FOO1_BIAS;
}

static inline double get_foo2 (void)
{
  extern double internal_foo1; /* typo! */
  return internal_foo1 + FOO1_BIAS;
}

To do that, the first decl of internal_foo1 has to survive past the
point where it goes out of scope, so it can be compared against the
new decl of the same object.

I've had a better idea, though.  Suppose we record all decls with
external linkage at file scope, even if they were declared at block
scope, but we tag them with an "ignore" bit when they leave the scope
they were declared in.  (Possibly C_DECL_ANTICIPATED can be reused for
this.)  That keeps them around for comparison with future decls of the
same object, but doesn't impose any overhead.

zw