Re: problem with C grammar

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
5 Jun 2006 20:46:35 -0400

          From comp.compilers

Related articles
[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 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)
Re: problem with C grammar mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-06-05)
| List of all articles for this month |

From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: 5 Jun 2006 20:46:35 -0400
Organization: cbb software GmbH
References: 06-05-078 06-06-015
Keywords: C, parse
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:
>
> 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


Post a followup to this message

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