When is a typedef name not a typedef name?

jwl@sag4.ssl.berkeley.edu (Jim Lewis)
Tue, 9 Jul 1991 03:12:43 GMT

          From comp.compilers

Related articles
When is a typedef name not a typedef name? jwl@sag4.ssl.berkeley.edu (1991-07-09)
Re: When is a typedef name not a typedef name? henry@zoo.toronto.edu (1991-07-20)
Re: When is a typedef name not a typedef name? mengel@fnal.fnal.gov (1991-07-31)
| List of all articles for this month |

Newsgroups: comp.lang.c,comp.compilers
From: jwl@sag4.ssl.berkeley.edu (Jim Lewis)
Keywords: C, parse, question
Organization: Space Science Labs
Date: Tue, 9 Jul 1991 03:12:43 GMT

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
--


Post a followup to this message

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