Re: ANSI C Yacc grammar

On 23 Oct 2001 20:25:38 -0400, Axel Kittenberger <axel@dtone.org>
wrote:


>> register int main()
>> {
>> return 1;
>> }
>
>register is eitherway a very deprecated keyword, today nearly no
>compiler/optimizer honors it (as far I know)


This might be true, but a function with return type register has
always bin illegal.




>> int main(int, int *, int)
>> {
>> return 2;
>> }
>
>What is exactly the problem? that main is used without argc, argv
>parameters?


No, the name 'main' was just a bad 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...




I think that would be a gcc extension, since ANSI C does not allow it
as far as I know. It is allowed for prototypes though.




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


No, that is not the same. It would be somewhat the same for arrays
with dimension 1, but even then there are differences.


The problem is that you have to specify the size of all dimensions of
the array, except for the first one, like int main(char a[][2][3]).
You have to do this even in prototypes and external variable
declarations.


But it is explained me by e-mail that if you add those checks to the
parser, you can easily fool it with:


typedef char string[];


int main(string a[])
{
}


So you have to check it after parsing anyway.




> 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.


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




OK, I do understand now that it is almost? impossible to do proper
type checking in the parser, but I think it would be possible to check
some more things than currently is done in the mentioned grammars.


I was planning to extend the grammer of the K&R book with additional
rules, but I now know that it would not be worth the trouble, since
there are so many other thinks that cannot be checked at the parser
state.




Thank you all for the feedback so far.


Greetings,
Gerwoud Otten.

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