|[2 earlier articles]|
|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 firstname.lastname@example.org (A.T.Hofkamp) (2006-05-30)|
|Re: problem with C grammar email@example.com (Russ Cox) (2006-05-30)|
|Re: problem with C grammar firstname.lastname@example.org (Ira Baxter) (2006-06-03)|
|Re: problem with C grammar email@example.com (Waldek Hebisch) (2006-06-03)|
|Re: problem with C grammar firstname.lastname@example.org (Dmitry A. Kazakov) (2006-06-05)|
|From:||"Dmitry A. Kazakov" <email@example.com>|
|Date:||5 Jun 2006 20:46:35 -0400|
|Organization:||cbb software GmbH|
|Posted-Date:||05 Jun 2006 20:46:35 EDT|
On 3 Jun 2006 19:00:19 -0400, Waldek Hebisch wrote:
> For example, if you see:
> int (* y)
> you could generate something like:
> / \
> int operator_unary_*
> and let the semantic analysis decide if the snippet above declares
> a pointer variable or is a call to a function named "int".
Yes, this is the way I do it all the time. int is considered an identifier,
which might be a type name, but it isn't parser's business.
> There a problem here: declarator in C is similar to expression, but
> not identical to it. If you do not know which one to expect you
> need to accept both, so the parser will accept a lot of junk.
True. A nasty problem, for example, is:
This requires introduction of an infix operator ' ':
bracket_operator_() // to distinguish it from operator_()
Then, of course, things like:
x y z + 3
might become legal expressions.
> But without good reason to do otherwise
> using symbol table to recognize types is the easiest method to
> parse C.
However for languages with a more reasonable grammar than C's one it works
nice. One advantage is that error messages generated during semantic
analysis are usually more informative than ones generated by lexer.
Dmitry A. Kazakov
Return to the
Search the comp.compilers archives again.