CODEWITHSUNDEEP
ccompiler-constructiongrammarbisoncontext-free-grammar
Alex Aparin
Alex Aparin

Reputation: 4522

Unexpected behavior of generated bison parser

I created parser via Flex/Bison, which unexpectedly fails during parsing. Here is simplified sample which shows problem

Lexer.l:

%{
#include "Parser.h"
%}
%option noyywrap nodefault

%%
"foo"               {   return FOO;                          }
"bar"               {   return BAR;                          }
"("                 {   return OP;                           }
")"                 {   return CP;                           }
[ \t\n]+            {   /*    DO NOTHING  */                 }
.                   {   YY_FATAL_ERROR("unknown character"); }
%%

And Parser.y (with enabled tracing and verbosity):

%{
#include <stdio.h>
int yylex();
void yyerror (char const *s);
%}

%debug
%verbose
%error-verbose
%token FOO BAR OP CP

%%
program_expr :   foo_expr bar_expr   {}
;
foo_expr :   /*  NOTHING  */  {}
    |   OP FOO CP           {}
;
bar_expr :   /*  NOTHING  */  {}
    |   OP BAR CP           {}
;
%%

int main(int argc, char** argv)
{
    yydebug = 1;
    yyparse();
    return 0;
}

void yyerror (char const *s) {  fprintf(stderr, "%s\n", s); }

But generated parser will fail if I specify input like (bar) - parse tree in that case should contain foo expression which is empty. It reports:

Starting parse

Entering state 0

Reading a token: Next token is token OP ()

Shifting token OP ()

Entering state 1

Reading a token: Next token is token BAR ()

syntax error, unexpected BAR, expecting FOO

Error: popping token OP ()

Stack now 0

Cleanup: discarding lookahead token BAR ()

Stack now 0

Here is piece of text from generated description of shift/reduce automata:

state 0
    0 $accept: . program_expr $end
    OP  shift, and go to state 1
    OP        [reduce using rule 2 (foo_expr)]
    $default  reduce using rule 2 (foo_expr)
    program_expr  go to state 2
    foo_expr      go to state 3


state 1
    3 foo_expr: OP . FOO CP
    FOO  shift, and go to state 4
state 2
    0 $accept: program_expr . $end
    $end  shift, and go to state 5
state 3
    1 program_expr: foo_expr . bar_expr
    OP  shift, and go to state 6
    $default  reduce using rule 4 (bar_expr)
    bar_expr  go to state 7

But I cannot understand meaning/syntax of such states. What's problem with my grammar/parser?

Upvotes: 2

Views: 255

Answers (2)

SKi
SKi

Reputation: 8476

If you want to accept just (bar) as input, you could use the following:

program_expr :   foo_expr bar_expr   {}
    |            bar_expr            {}
;

instead of this:

program_expr :   foo_expr bar_expr   {}
;

Test output:

> echo "(bar)" | ./Parser 
Starting parse
Entering state 0
Reading a token: Next token is token OP ()
Shifting token OP ()
Entering state 1
Reading a token: Next token is token BAR ()
Shifting token BAR ()
Entering state 6
Reading a token: Next token is token CP ()
Shifting token CP ()
Entering state 11
Reducing stack by rule 6 (line 20):
   $1 = token OP ()
   $2 = token BAR ()
   $3 = token CP ()
-> $$ = nterm bar_expr ()
Stack now 0
Entering state 4
Reducing stack by rule 2 (line 14):
   $1 = nterm bar_expr ()
-> $$ = nterm program_expr ()
Stack now 0
Entering state 2
Reading a token: Now at end of input.
....

Upvotes: 3

Thomas G.
Thomas G.

Reputation: 175

Bison generates by default LALR(1) parsers. LALR(1) stands for look ahead 1 token left to right parser.

Your grammars is not LALR(1). On OP it is not clear if to expect a foo or a bar. That is a reduce/reduce conflict.

Look here: https://en.wikipedia.org/wiki/LALR_parser

But generally Bison could generate an LR parser. At least a wiki entry here claims that: https://en.wikipedia.org/wiki/GNU_Bison

Your case is a "mysterious conflict": https://www.gnu.org/software/bison/manual/html_node/Mysterious-Conflicts.html#Mysterious-Conflicts

Upvotes: 3

Related Questions