Re: YACC->Bison

kerrr@my-dejanews.com
described an error


    ("idr_parser.y", line 107) error: type clash (`' `token_id') on default
action


produced by surprise from bison (and apparently not by yacc), from the
following lines
<<


102: statements :
103: | statements statement
104: ;
105:
106: statement : END
107: | command END
108: {
109: debug_idr_num("statement", "END", "number of entries",
(Real)cntr);


>>


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
    yada;
or
    {yada;};


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


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
`token_id'.


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
                          || strcmp(lhs->type_name,first_rhs->type_name))
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,
and
    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.


Best Wishes,
Robert Rayhawk
RKRayhawk@aol.com

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