[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange behavior
From: |
Hans Aberg |
Subject: |
Re: Strange behavior |
Date: |
Thu, 25 Mar 2004 19:15:07 +0100 |
At 12:35 +0100 2004/03/25, Laurent Deniau wrote:
>I am using Bison 1.35 and 1.875 to parse the ISO C99 grammar and I found
>a strange behavior on a very simple case:
This is not really a Bison question, but a question of implementing a
language using the LALR(1) parsing algorithm. As your language is
well-known, it might be worthwhile asking around in the newsgroup
comp.compilers, or in some of the C newsgroups to see if somebody already
has done it. Some C compilers might already have it (GNU C?).
Also, it is really a Help-Bison <address@hidden>, question, not a
Bug-Bison question.
>If I use the rule:
>
>direct_abstract_declarator
> : '(' abstract_declarator ')'
> | direct_abstract_declarator_opt '[' assignment_expression_opt ']'
> | direct_abstract_declarator_opt '[' '*' ']'
> | '(' parameter_type_list_opt ')'
> | direct_abstract_declarator '(' parameter_type_list_opt ')'
> ;
>
>I have only one shift/reduce conflict for all the grammar (the IF ELSE
>one). But if I use the rule
You can resolve the dangling else problem by setting token precedences on
the THEN and ELSE tokens (using say %nonassoc). In C, one should probably
set a precedence on ")" then.
Tip: It is might be better to avoid the single quote ')' constructs, and
instead use
%token LP "("
%token RP ")"
...
%%
...>direct_abstract_declarator
: "(" abstract_declarator ")"
Then your Flex grammart must have lines
"(" { return RP; }
etc.
Hans Aberg