Re: problem with C grammar

"Ivan A. Kosarev" <ik@unicals.com>
26 May 2006 12:48:48 -0400

          From comp.compilers

Related articles
problem with C grammar the.malfunction@googlemail.com (the.malfunction@googlemail.com) (2006-05-26)
Re: problem with C grammar ik@unicals.com (Ivan A. Kosarev) (2006-05-26)
Re: problem with C grammar DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-30)
Re: problem with C grammar cfc@shell01.TheWorld.com (Chris F Clark) (2006-05-30)
problem with C grammar a.t.hofkamp@tue.nl (A.T.Hofkamp) (2006-05-30)
Re: problem with C grammar rsc@swtch.com (Russ Cox) (2006-05-30)
Re: problem with C grammar idbaxter@semdesigns.com (Ira Baxter) (2006-06-03)
Re: problem with C grammar hebisch@math.uni.wroc.pl (Waldek Hebisch) (2006-06-03)
[1 later articles]
| List of all articles for this month |
From: "Ivan A. Kosarev" <ik@unicals.com>
Newsgroups: comp.compilers
Date: 26 May 2006 12:48:48 -0400
Organization: Compilers Central
References: 06-05-078
Keywords: C, parse
Posted-Date: 26 May 2006 12:48:48 EDT

<the.malfunction@googlemail.com> wrote in message


> As it seems, the lexical scanner is proposed to analyse whether an
> identifier is a type or not. I rather would like to let the parser do
> this job. Is there any way to change the grammar such that I can use
> IDENTIFIER instead of TYPE_NAME here without having all those conflicts?


Nope. While you have to differentiate these grammar entities they can be
represented with the exactly same portions of tokens. For example, the
following expression statement can be parsed as designating both subtraction
by 1 (when id is declared as, say, int id;) and cast (-1) to some type id
(when id is declared as, say, typedef int id;).


(id) - 1;


But it's not actually a great problem to look into symbol table to determine
what a given identifier designate. The only thing you would probably have to
handle in a special way is declarations like in the following cases:


typedef int T;


{
        float T; // T is declarator, not a type specifier here
}


{
        T const T; // again, second T is not a type specifier here, although
first T is
}


--
Unicals Group -- Embedded C++ for Your IP Cores
http://www.unicals.com



Post a followup to this message

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