Re: YACC->Bison (RKRayhawk)
20 May 1999 01:48:31 -0400

          From comp.compilers

Related articles
YACC->Bison (1999-05-16)
Re: YACC->Bison (1999-05-20)
Re: YACC->Bison (Javeed Ahmed) (1999-09-10)
| List of all articles for this month |

From: (RKRayhawk)
Newsgroups: comp.compilers
Date: 20 May 1999 01:48:31 -0400
Organization: AOL
References: 99-05-053
Keywords: yacc, errors
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
following lines

102: statements :
103: | statements statement
104: ;
106: statement : END
107: | command END
108: {
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
                          || 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,
    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

Post a followup to this message

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