[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with bison creating a GLR parser
From: |
S. Eken |
Subject: |
Problems with bison creating a GLR parser |
Date: |
Mon, 27 Jan 2003 08:50:31 +0100 (MEZ) |
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
- Problems with bison creating a GLR parser,
S. Eken <=