How to avoid conflicts between yacc C grammar multiplication and pointer？ - yacc

Question

I'm yacc beginner
C grammar multiplication and pointer
a = 10 ***** b
How to distinguish multiplication from pointer?
I think it can only be deduced according to the type of b?
Actually, I saw some examples:
http://www.quut.com/c/ANSI-C-grammar-l-2011.html
and
https://github.com/JavinYang/go-1/blob/release-branch.go1/src/cmd/gc/go.y
I don't understand why these two examples don't cause reduce/reduce conflicts
I imitate the above code will cause conflicts
logical_and_expression
: equality_expression
| logical_and_expression LOGICAL_AND equality_expression
{
$$ = 0;
}
;
equality_expression
: relational_expression
| equality_expression EQ relational_expression
{
$$ = 0;
}
| equality_expression NE relational_expression
{
$$ = 0;
}
;
relational_expression
: additive_expression
| relational_expression GT additive_expression
{
$$ = 0;
}
| relational_expression GE additive_expression
{
$$ = 0;
}
| relational_expression LT additive_expression
{
$$ = 0;
}
| relational_expression LE additive_expression
{
$$ = 0;
}
;
additive_expression
: multiplicative_expression
| additive_expression ADD multiplicative_expression
{
}
| additive_expression SUB multiplicative_expression
{
};
multiplicative_expression
: unary_expression
| multiplicative_expression MUL unary_expression
{
}
| multiplicative_expression DIV unary_expression
{
}
unary_expression
: primary_expression
| MUL unary_expression // cause reduce/reduce conflicts
{
}
| SUB unary_expression
{
}
| EXCLAMATION unary_expression
{
}
| BIT_XOR unary_expression
{
}
;
y.output conflicts line:
state 85
79 multiplicative_expression: unary_expression .
83 unary_expression: MUL unary_expression .
LOGICAL_AND reduce using rule 79 (multiplicative_expression)
LOGICAL_AND [reduce using rule 83 (unary_expression)]
LOGICAL_OR reduce using rule 79 (multiplicative_expression)
LOGICAL_OR [reduce using rule 83 (unary_expression)]
EQ reduce using rule 79 (multiplicative_expression)
EQ [reduce using rule 83 (unary_expression)]
NE reduce using rule 79 (multiplicative_expression)
NE [reduce using rule 83 (unary_expression)]
GT reduce using rule 79 (multiplicative_expression)
GT [reduce using rule 83 (unary_expression)]
GE reduce using rule 79 (multiplicative_expression)
GE [reduce using rule 83 (unary_expression)]
LT reduce using rule 79 (multiplicative_expression)
LT [reduce using rule 83 (unary_expression)]
LE reduce using rule 79 (multiplicative_expression)
LE [reduce using rule 83 (unary_expression)]
ADD reduce using rule 79 (multiplicative_expression)
ADD [reduce using rule 83 (unary_expression)]
SUB reduce using rule 79 (multiplicative_expression)
SUB [reduce using rule 83 (unary_expression)]
MUL reduce using rule 79 (multiplicative_expression)
MUL [reduce using rule 83 (unary_expression)]
DIV reduce using rule 79 (multiplicative_expression)
DIV [reduce using rule 83 (unary_expression)]
NEW_LINE reduce using rule 79 (multiplicative_expression)
NEW_LINE [reduce using rule 83 (unary_expression)]
$default reduce using rule 79 (multiplicative_expression)

Answer 1

There's no conflict because multiplication is infix and pointer dereference is prefix, so they can be disambiguated from context, trivially in an LALR(1) parser. The fragment you post above has no conflicts, so the conflicts you show are actually coming from some other rule.
Most likely from a rule that allows two consecutive expressions with no token separating them, eg (function_application: expression expression ;). If you have such a rule combined with operators that may be infix or prefix (such as - or *), the result is ambiguous as a - b can be parsed as (a) (- b) (function application + unary) or as a binary operation. To disambiguate this (and the related ambiguity of applying a unary operation to the result of function application), you can make the operands of function application primaries: function_application: primary_expression | primary_expression function_application ;