Related articles |
---|
ANSI C Yacc grammar g.w.otten@ato.dlo.nl (2001-10-20) |
Re: ANSI C Yacc grammar GOLDParser@DevinCook.com (2001-10-23) |
Re: ANSI C Yacc grammar axel@dtone.org (Axel Kittenberger) (2001-10-23) |
Re: ANSI C Yacc grammar g.w.otten@ato.dlo.nl (2001-10-27) |
From: | Axel Kittenberger <axel@dtone.org> |
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
generator.
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
everything.
From the comp.compilers FAQ, I found this book an excelent read if one is
interested on the parsing techs themselfs:
http://www.cs.vu.nl/~dick/PTAPG.html
So normally we use simpler parsers, and than do the more sophisticated
checks later.
- Axel
--
|D) http://www.dtone.org
Return to the
comp.compilers page.
Search the
comp.compilers archives again.