When is a typedef name not a typedef name?

I'm working on a utility that includes a C parser, and I've hit a snag with
overloading of typedef names. The problem is that typedef names and
struct/union members are in different namespaces, so that the following code
is legal:




typedef int foo;


struct bar
{
      foo foo;
};


main()
{
        struct bar blah;
        foo bletch;


        blah.foo = 1;


        /* ... */
}


It turns out that the "foo foo;" declaration is only legal inside a
struct or union -- if one were to try to declare a variable named foo
within the scope of the typedef, a syntax error would result.


I've been working with a yacc grammar for C that is almost identical to
the one in uunet:net.sources/ansi.c.grammar.Z -- there are no explicit
allowances in that grammar for allowing typedef names in the rules for
struct_declarator_list or primary_expression.


I've looked at the GCC parser, which uses a somewhat different grammar,
but the trick seems to be to find the right way to provide feedback to the
lexical analyzer, so that it will return an IDENTIFIER token for "foo"
used as a struct/union member, and a TYPE_NAME token the rest of the
time.


I don't really understand what GCC is doing -- its lexical analyzer
seems to be doing some kind of lookup of the last declaration of an
identifier before deciding whether to return an IDENTIFIER or a TYPE_NAME.


Rewriting the grammar seems hopeless -- every variation I've come up
with resulted in reduce/reduce conflicts.


Has anyone modified ansi.c.grammar (or the lexical analyzer that comes
with it) to address this problem? Believe it or not, I've actually
found code that relies on overloading of identifiers and typedef names,
and I'd *really* like to be able to run it through my parser!


Thanks,


-- Jim Lewis
      U.C. Berkeley
      Center for EUV Astrophysics
--

Return to the comp.compilers page.
Search the comp.compilers archives again.