Re: ANSI C Yacc grammar

Axel Kittenberger <>
23 Oct 2001 20:25:38 -0400

          From comp.compilers

Related articles
ANSI C Yacc grammar (2001-10-20)
Re: ANSI C Yacc grammar (2001-10-23)
Re: ANSI C Yacc grammar (Axel Kittenberger) (2001-10-23)
Re: ANSI C Yacc grammar (2001-10-27)
| List of all articles for this month |

From: Axel Kittenberger <>
Newsgroups: comp.compilers
Date: 23 Oct 2001 20:25:38 -0400
Organization: Kabelsignal AG Broadband Service
References: 01-10-101
Keywords: C, parse
Posted-Date: 23 Oct 2001 20:25:38 EDT

> register int main()
> {
> return 1;
> }

register is eitherway a very deprecated keyword, today nearly no
compiler/optimizer honors it (as far I know)

> int main(int, int *, int)
> {
> return 2;
> }

What is exactly the problem? that main is used without argc, argv
parameters? could be a problem yes, since main is defined to have
exactly these parms and non else. (I believe that this is even in the
ANSI standard) or is it that the parameter names are omited? (and you
took 'main' only as example)

Actually I believe omiting the names is legal after all, altough gcc does
do warnings. In some cases you want a function to fit a specific prototype
so a function pointer type matches to it, but you donnot use the parameter
at all...

> int main(char a[][][])
> {
> }

that would be the same as writing 'int main (char ***a)' or? hmmm whats
exactly the problem with that?

> Why is this input accepted ? Is it not possible to write a grammar
> which is more close to the ANSI C syntax ? I understand that a yacc
> based grammmer could not do things like type checking and parameter
> checking etc, but a better syntax checking seems possible to me.

What I understood is that you've two levels of error checking,
- syntactic and symantic.

Syntactic Is The One that is checked by the parser.

Semantic Error checking is more complicated and some checks are executed in
the rules, or even later at the syntax tree.
like :
int i = "hallo";

is syntactic correct C, but symantic the types will not match.

> [I find that I can generate much better error messages by accepting
> a larger language in the parser and then rejecting the excess later.
> -John]

Yes what john said :o)

One could theoretically write a grammar that checks directly everything at
parsing state, but this would be a level 0 grammar, meaning (nearly)
impossible to implent to write and to understand, something as far I know
humanity not yet managed :o) (there is no generic level 0 grammar parser
Level 0 Means You Can have more than one token on the left side of the
rules, without any additional restrictions), there are some for level 1,
which is I guess that you have never more token on the left side than on
the right side, but they take already huge compilation time (non linear
compile time relative to the input) "normal" grammars we are used to are
level 3, thus only allowing one token on the left hand side, so called
context-free languages. They are easy to implement but cannot check

From the comp.compilers FAQ, I found this book an excelent read if one is
interested on the parsing techs themselfs:

So normally we use simpler parsers, and than do the more sophisticated
checks later.

- Axel

Post a followup to this message

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