|YACC->Bison firstname.lastname@example.org (1999-05-16)|
|Re: YACC->Bison email@example.com (1999-05-20)|
|Re: YACC->Bison firstname.lastname@example.org (Javeed Ahmed) (1999-09-10)|
|Date:||20 May 1999 01:48:31 -0400|
described an error
("idr_parser.y", line 107) error: type clash (`' `token_id') on default
produced by surprise from bison (and apparently not by yacc), from the
102: statements :
103: | statements statement
106: statement : END
107: | command END
109: debug_idr_num("statement", "END", "number of entries",
This may not be a line counting problem, but a genuine coding error. The
posted code shows no close curly brackets. Proper form of actions are either
Obviously, the original code may have the close bracket, and it is
only the cut and paste actions for posting and editing the newsgroup
article that leave the impression of a missing curly bracket.
(If so, please ignore the rest of this posting!)
If the hunch is correct, then either yacc and bison differ in their
ability to compensate for this coding error, or the real original
source code never confronted yacc with the missing close bracket: that
is, the error might have been introduced during the source code
modification effort for the conversion to the bison development
If the hunch is correct, the matter that looks like an explicit action
is instead an embedded action of the rule, and there is not an
explicit action. So bison generates the default $$ = $1. This is
happening right at line 107.
Perhaps the symbol 'command' (which is $1 at line 107) can in one way
or another return a type `token_id', or perhaps the first pattern
which is simply the token 'END' (which is alternatively $1) returns
The elegant piece of bison that traps this problem is a case structure
coded as a sequence of if/else-if statements dealing with default
actions (!xactions) in reader.c, as follows
/* If $$ is being set in default way,
warn if any type mismatch. */
else if (!xactions && first_rhs && lhs->type_name != first_rhs->type_name)
if (lhs->type_name == 0 || first_rhs->type_name == 0
warnss("type clash (`%s' `%s') on default action",
lhs->type_name ? lhs->type_name : "",
first_rhs->type_name ? first_rhs->type_name : "");
So in the example being discussed
lhs->type_name is null,
first_rhs->type_name = `token_id'
which seems to be coming from symbol 'command' or the token 'END'.
I think that in order for this explanation to be viable, that LHS symbol
'statement' must have been declared without a type. Which is not a problem in
many cases where the test
lhs->type_name != first_rhs->type_name
fails to trigger a diagnostic, since 0 == 0, and $$ = $1 will work just fine.
I haven't looked further to see what bison is doing here in the clash
detection. Is it chekcing
$$ vis-a-vis $1 for each of the multiple rules, or just for the first, because
if the hunch is right it doesn't matter. Yet if this interesting example is
instructive, it is noteworthy that probably each of the multiple rules needs to
be checked in default as well as in explicit action specifications.
Return to the
Search the comp.compilers archives again.