Re: problem with C grammar

On 3 Jun 2006 19:00:19 -0400, Waldek Hebisch wrote:


> For example, if you see:
>
> int (* y)
>
> you could generate something like:
>
> operator_()
> / \
> int operator_unary_*
> \
> y
>
> 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:


      (int) x


This requires introduction of an infix operator ' ':


implied_operator
      / \
    / x
  |
bracket_operator_() // to distinguish it from operator_()
          |
        int


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.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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