Problems with bison creating a GLR parser

[S. Eken]

Hello,

While trying out the glr parser capabilities of bison (version
1.875) I ran into a strange problem and finally tracked it down
to small bit of code.

The grammar is supposed to understand the following commands:

set <variable> to <value>
set <variable, variable, ...> to <expression>

represented by lower resp. upper case letters:
s V t v
s V,V t e

The problem occurs when I try to insert some C-code within a
rule consisting of several tokens:

command:
  's' var 't'
  { fprintf (stderr, "Statement variable: '%s' (%p)\n", $2, $2);
  } 'v'
  .
  .
  .
  ;

In this case, if I create a string pointer in

var:
  'V'
  { $$ = strdup ("VARIABLE");
    fprintf (stderr, "Variable: created '%s' (%p)\n", $$, $$);
  }
  ;

which is supposed to be passed as $2 in the first rule of 'command'
they turn out to be not the same. What's even more, if I debug the
programm and break on the execution of fprintf in the 'command' rule,
I found that yyuserAction is called with yyrhslen=0, which indicates,
as I understand, the presence of no token at all.

Looking at the second command,

command:
  .
  .
  .
  | 's' var_list 't' 'e'
  { fprintf (stderr, "Statement varlist: '%s' (%p)\n", $2, $2);
  }
  ;

the pointer is correctly passed as $2 and yyuserAction is called with
yyrhslen=4, which seems to be the number of tokens.

Hmmmm???

This problem never occurs without the %glr-parser switch.

I produced a small example to demonstrate what I described and I
include the files in this mail for a quick glance at it. (They can
also be found in the attachment.)

I hope you can help me with this. I am not sure if it is my
misunderstanding of the way rules have to be coded in bison,
but the fact that the non-glr parser accepts this, seems to
suggest the correctness of my approach.

Thanks in advance

Sebastian Eken
address@hidden

*********************************
glr.y
*********************************

%{
  #define YYSTYPE char const *
  #define yyfalse 0
  #define yytrue 1

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

%glr-parser

%%

command:
  's' var 't'
  { fprintf (stderr, "Statement variable: '%s' (%p)\n", $2, $2);
  } 'v'
  | 's' var_list 't' 'e'
  { fprintf (stderr, "Statement varlist: '%s' (%p)\n", $2, $2);
  }
  ;

var:
  'V'
  { $$ = strdup ("VARIABLE");
    fprintf (stderr, "Variable: created '%s' (%p)\n", $$, $$);
  }
  ;

var_list:
  var
  { $$ = $1;
    fprintf (stderr, "Varlist: passing '%s' (%p)\n", $1, $1);
  }
  | var ',' var_list
  ;

%%

FILE *yyin = NULL;

int
yylex (void)
{ int c;
  char buf[50];
  while ((c = fgetc (yyin)) == ' ' || c == '\t' || c == '\n') ;
  if (c == EOF) return 0;
  buf[0] = c;
  buf[1] = 0;
  yylval = strdup (buf);
  return c;
}

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

int
main (int argc, char **argv)
{ yyin = stdin;
  if (argc == 2 && !(yyin = fopen (argv[1], "r"))) return 1;
  return yyparse ();
}

*********************************
Makefile
*********************************

all: glr

glr: glr.o
        gcc -g -o glr glr.o

glr.o: glr.c
        gcc -g -c glr.c

glr.c:
        bison -o glr.c glr.y

clean:
        @rm -f glr.o glr.c glr

*********************************
test1
*********************************
s V t v

*********************************
test2
*********************************
s V,V t e

*********************************
To demonstrate the effect, call
  glr test1 (for 'incorrect' output)
or
  glr test2 (for 'correct' output)
*********************************

glr-example.tar.gz
Description: Binary data