Re: C Grammar Quirk

fsergeev@my-deja.com
31 Dec 2000 03:00:14 -0500

          From comp.compilers

Related articles
C Grammar Quirk rcbilson@plg2.math.uwaterloo.ca (Richard C Bilson) (2000-12-20)
Re: C Grammar Quirk fsergeev@my-deja.com (2000-12-31)
| List of all articles for this month |
From: fsergeev@my-deja.com
Newsgroups: comp.compilers
Date: 31 Dec 2000 03:00:14 -0500
Organization: Deja.com
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 |
non-function-declarator.


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


Anyone with better ideas?


Fedor.


    Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca> 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.