[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug Using GLR parser. Symptom is an occasional incorrect pattern match
From: |
Levo |
Subject: |
Bug Using GLR parser. Symptom is an occasional incorrect pattern match |
Date: |
Wed, 9 Dec 2009 10:08:27 -0800 (PST) |
I found a bug using bison 2.4.1, i cant think of a work around or a solution.
In my lex file
[0-9]+ { return INTEGER; }
in my test.y file
ValLiteral:
INTEGER
{ $$ = strdup(yytext); printf("Is this a int? %s\n",
yytext); }
INTEGER is ONLY use in ValLiteral. In my .y file i searched { $$ and replace
with //{ $$. I then removed the comment for only the rule above. My output
shows
Is this a int? 5
Is this a int? ,
...
As you can see ',' is not an int. When i remove %glr-parser i get the
correct values however i also receives syntax errors due to conflicts in my
language (4 shift/reduce). All 4 errors related to Vars and Type colliding.
I traced the bug down to a specific rule. After putting a dummy token i get
the correct value with either path. I wont go into more details unless
someone would like to correct the bug. I prefer not to publicly post my
files so email me if your interested in correcting the bug.
--
View this message in context:
http://old.nabble.com/Bug-Using-GLR-parser.-Symptom-is-an-occasional-incorrect-pattern-match-tp26714834p26714834.html
Sent from the Gnu - Bison - Bugs mailing list archive at Nabble.com.
- Bug Using GLR parser. Symptom is an occasional incorrect pattern match,
Levo <=