Re: Parsing C: identifier VS typedef name

> But the grammar is dependent on distinguishing IDENTIFIER and
> TYPEDEFname even in declarations. So here's the problem: how can the
> lexer learn at the point of declaration *WHAT* is that
> identifier-like string, IDENTIFIER or TYPEDEFname? We didn't store
> it in any symbol table yet, we want to parse the declaration!


If you haven't already parsed a copy of the identifier-like string in
a "previous" declaration, then the string at this point is an
IDENTIFIER. It is only a TYPEDEFname if it was made a TYPEDEFname by
a previous declaration.


However, note that the point of declaration is very important in C.
The identifier is supposed to be declared at the instant it is reduced
to a declarator (usually upon seeing a comma, semicolon, or equals,
but also if I recall correctly upon seeing an open bracket or
parenthesis or a close paren). That means that exactly upon the point
of making that reduction, one is supposed to make the relevant entry
in the symbol table (not before nor after).


The upshot of this is is you see the following declarations:


typedef int t;
t j = 3;


The t is an IDENTIFIER until the 1st ; is seen (in the declaration of
t, t is an IDENTIFIER) and then it becomes a TYPEDEFname for its next
use (in the declaration of j).


The subtle points are declarations like:


typedef int t, p(t);


In the above statement, t is an IDENTIFIER upto the comma and then a
TYPEDEFname after the comma in the declaration of the p which is a
typedef describing a function with a single parameter of type t.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

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