Re: Parsing C: identifier VS typedef name

DrDiettrich <drdiettrich@compuserve.de>
26 Apr 2005 20:38:35 -0400

          From comp.compilers

Related articles
Parsing C: identifier VS typedef name igor@SB8286.spb.edu (Igor Baltic) (2005-04-16)
Re: Parsing C: identifier VS typedef name cfc@world.std.com (Chris F Clark) (2005-04-17)
Re: Parsing C: identifier VS typedef name idbaxter@semdesigns.com (Ira Baxter) (2005-04-17)
Re: Parsing C: identifier VS typedef name drdiettrich@compuserve.de (DrDiettrich) (2005-04-26)
| List of all articles for this month |

From: DrDiettrich <drdiettrich@compuserve.de>
Newsgroups: comp.compilers
Date: 26 Apr 2005 20:38:35 -0400
Organization: Compilers Central
References: 05-04-046
Keywords: C, parse

Igor Baltic wrote:


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


As you found out yourself, such a distinction requires a symbol table,
at least a typedef table.


> [There's a variety of answers, all kludges. -John]


Agreed.


I've put the distinction into the link between the preprocessor and
the parser, where the preprocessor tokens are filtered and possibly
converted into high level language tokens. A symbol table is already
required for the detection and consequential expansion of macros
(#define), and for the evaluation of preprocessor expressions with
named constants. The symbol type, as stored with every symbol in that
table, then can be used to distinguish typedef names from other
identifiers.


DoDi



Post a followup to this message

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