Re: C Grammar Quirk
31 Dec 2000 03:00:14 -0500

          From comp.compilers

Related articles
C Grammar Quirk (Richard C Bilson) (2000-12-20)
Re: C Grammar Quirk (2000-12-31)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: 31 Dec 2000 03:00:14 -0500
References: 00-12-092
Keywords: C, standards
Posted-Date: 31 Dec 2000 03:00:14 EST

Recently stumbled on the same problem in my compiler. Due to this rule
it significantly suffers in error recovering. However I realized that
its quite costly to change it to not accept non-function declarators.

First, you need rule for function-declarator. Yep, its not that
hard. But then (to avoid conflicts) you need to split
direct-declarator in two pieces - function-declarator |

Thus ~5 lines rule becomes ~20-30 lines monster (and now it is not
that clear to understand).

Anyone with better ideas?


    Richard C Bilson <> wrote:
> My research group is exploring different C grammars for use in a project,
> and we're a little surprised by a "feature" we found in the grammar in the
> ANSI C standard (and, as a result, in many of the freely available YACC
> grammars). The curious construction is (from the C99 standard):
> function-definition:
> declaration-specifiers declarator declaration-list_opt \
> compound-statement
> declarator:
> pointer_opt direct-declarator
> direct-declarator:
> identifier
> ( declarator )
> direct-declarator [ assignment-expression_opt ]
> direct-declarator [ * ]
> direct-declarator ( parameter-type-list )
> direct-declarator ( identifier-list_opt )
> So the following program:
> #include <stdio.h>
> int foo[] { printf("foo!"); }
> is syntactically valid. Many grammars I have tried (e.g. Roskind's
> C89 grammar) accept this. It is semantically bogus, of course, and is
> rejected as such by any compiler I've tried. But that kind of construct
> is *never* valid, so it could be rejected by the parser.

Post a followup to this message

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