[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reductions during Bison error handling

From: Paul Hilfinger
Subject: Reductions during Bison error handling
Date: Thu, 09 May 2002 19:48:23 -0700

The code for bison.simple contains the following:

    #if 0
      /* This is wrong; only states that explicitly want error tokens
         should shift them.  */

      /* If its default is to accept any token, ok.  Otherwise pop it.  */
      yyn = yydefact[yystate];
      if (yyn)
        goto yydefault;

I suspect that the comment and the #if 0 ... #endif are wrong.  

1. The comment is certainly wrong or at least extremely obscure: it
   speaks of shifting, but the code applies only to (default) reductions.

2. Consider the following contrived example (which is LALR(1), without

        prog: 'x' 'y' 'z' ';' 
            | r error ';' { printf (" *error action*\n"); }
            | q ';'

        r : 'x'

        q : 'x'

   If you compile this with an appropriate trivial lexer, and put
   through it the erroneous input string


   you will find that "*error action*" is NOT printed.  

   If on, the other hand, you enter 

        prog: 'x' 'y' 'z' ';' 
            | r error ';' { printf (" *error action*\n"); }
            | q ';'

        q : 'x'

        r : 'x'

   (note that the last two productions are reversed) you see that
   "*error action*" IS printed.  

What's going on?  Well, in the first example, Bison chooses r : 'x'
as the default reduction, whereas it chooses q : 'x' as the default
reduction.  The result of suppressing the code at the top is that the
reduction to r is not taken if it is a default reduction.  If r : 'x'
is NOT a default reduction, then the code under yyerrhandle eventually
takes you to yyreduce rather than yyerrdefault.  

I don't know what all the reasoning is behind this change (which dates
back to pre-version 1.1 of the file, ca 1993).  I presume it is
supposed to correct some perceived misbehavior or another.  Does
anyone know what?

Paul Hilfinger

reply via email to

[Prev in Thread] Current Thread [Next in Thread]