[antlr-interest] C grammar problem

Monty Zukowski monty at codetransform.com
Fri Jan 5 10:05:40 PST 2007

You're probably right that it is a bug in cgram.  I don't remember
having a test quite like that one.  You are also probably on the right
track to believe that it has to do with guessing mode.  If you can
pinpoint the rules where this fails I might be able to help you solve
it, but I don't have the time to figure it out on my own.

There are ways to have "side effects" when in guessing mode, which is
probably what you will need to do to get T into the symbol table.

The other option is to see if the syntactic predicate can be truncated
in such a way as to match enough of a prefix to correctly know which
decision to make, without having to parse as far ahead as it is now,
which is what is getting it into trouble.


On 1/5/07, Jan Obdrzalek <obdrzalek at gmail.com> wrote:
> Hello,
> I think I've encountered a problem in the cgram C grammar. The code
> below can pass "gcc -c -std=c89" (i.e. should be allright as far as
> ISO C89 standard is concerned), but GnuCParser from cgram crashes on
> it.
> <<< test.c <<<
> void a(void){
>        int a=5;
>        struct s *ps=({
>        typedef int T;
>        T t;
>        &a;
>        });
>        return;
> }
> >>> test.c >>>
> I've tried to investigate the problem and found that it looks to be
> caused by the following sequence of steps:
> - when the parser first encounters the initializer of ps (which is a
> compound statement),  the action of opening new scope is not executed
> because the parser is in "guess mode"
> - for the same reason the new type T not added to the symbol table
> - when "T t" is encountered, the check whether T is a tyoedef name
> fails, since there is no typedef name T in our current symbol table
> Have I missed something, or is it genuine error in cgram? Is there an
> easy way to fix this?
> Thanks,
> Jan

More information about the antlr-interest mailing list