C Grammar Quirk

Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
20 Dec 2000 17:22:55 -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: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
Newsgroups: comp.compilers
Date: 20 Dec 2000 17:22:55 -0500
Organization: Compilers Central
Keywords: C, question
Posted-Date: 20 Dec 2000 17:22:54 EST

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):

                    declaration-specifiers declarator declaration-list_opt \

                    pointer_opt direct-declarator

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

I understand that some issues of syntax are better left to semantic
analysis, but I don't see why that applies in this case. It does make the
grammar "simpler" (in terms of fewer productions vs. having a separate
"function-declarator" non-terminal), but it makes things harder for me to
understand -- what's the point in having a standard grammar if it doesn't
precisely define valid syntax?


Richard C. Bilson http://plg.uwaterloo.ca/~rcbilson
                    Programming Languages Group, University of Waterloo

Post a followup to this message

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