headers
Levo | 9 Dec 19:08
Picon

Bug Using GLR parser. Symptom is an occasional incorrect pattern match


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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel E. Denny | 9 Dec 21:36
Favicon

Re: Bug Using GLR parser. Symptom is an occasional incorrect pattern match

On Wed, 9 Dec 2009, Levo wrote:

> 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? ,

yytext is the text of the last token scanned.

You seem to expect yytext to be the text for $1.  Even without GLR, that's 
not always true because, depending on your grammar, there might be a 
lookahead.  With GLR, it's especially difficult to predict when it's true 
because some parser actions are deferred until after the scanner has 
recognized many more tokens.

I recommend you make your scanner store yytext in yylval.  In your parser
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 10 Dec 19:48
Favicon

Re: Bug Using GLR parser. Symptom is an occasional incorrect pattern match

On Thu, 10 Dec 2009, levo.delellis <at> gmail.com wrote:

> Hey your reply in "Re: Bug Using GLR parser. Symptom is an occasional 
> incorrect pattern match" solved the problem.

I'm glad it helped.

> Thanks. I'm going to delete 
> the thread thus i am emailing.

I've added back bug-bison.  In the future, please don't drop the mailing 
list even if you're just saying "thanks, that worked", which can be useful 
information to others reading the thread.

> Your solution was to use yylval. I skimmed the code samples and didnt 
> notice it while reading Flex & Bison. I'm surprised i got more then half 
> way before running into this problem. Thanks.

If you're still looking for it, see page 8.
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 16 Dec 00:33
Favicon

Re: [PATCH] build: avoid printf format mismatch warnings

On Sun, 11 Oct 2009, Joel E. Denny wrote:

>   http://lists.gnu.org/archive/html/bug-gnulib/2009-10/msg00108.html
> 
> Based on that discussion, I'm thinking of pushing the following.  I'm 
> hesitating for a few reasons:
> 
> 1. I'm not sure why bootstrap.conf was careful to exclude 
> m4/printf-posix.m4.  Maybe to avoid bloat?

Given that the comments say "we don't need them", I'm assuming the point 
was to avoid bloat.  However, -DGNULIB_POSIXCHECK recommends printf-posix, 
so I'm removing the exclusion of m4/printf-posix.m4.

> 2. -DGNULIB_POSIXCHECK suggests realloc-posix for the sake of 
> vasnprintf.c, so it seems realloc-posix ought to be a dependency of 
> vasnprintf-posix.  I'll explore further later and maybe take it to the 
> gnulib maintainers.

On second thought, maybe realloc-posix doesn't fix any feature of realloc 
actually needed by vasnprintf-posix, but -DGNULIB_POSIXCHECK of course 
isn't precise enough to realize that.  I'm not going to pursue this with 
the gnulib maintainers.

> 3. -DGNULIB_POSIXCHECK is suggesting a lot of other modules.  We need to 
> explore those at some point.

Later.

> 4. I'm trying to decide whether to apply the patch to branch-2.4.2.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 16 Dec 01:18
Favicon

Re: Non-portable m4 check in autoconf 2.64, 2.65, HEAD

Hi Eric,

On Fri, 27 Nov 2009, Eric Blake wrote:

> According to Harald van Dijk on 11/26/2009 11:32 AM:
> > The configure script of autoconf 2.64/2.65/HEAD fails to detect a
> > suitable m4 on my system.
> > I have GNU M4 1.4.13. The problem is that I'm using dash for /bin/sh
> > (and my dash supports LINENO so configure doesn't silently use bash
> > instead), and the m4 detection doesn't work when echo \1 prints ^A.
> 
> That means bison needs to update its autoconf submodule to today, or it
> will suffer from the same problem in its reuse of the broken m4.m4 test.

Thanks.  I pushed the first patch below to master and branch-2.5.  I 
pushed the second to branch-2.4.2.

From c843aaab352ab1f40c7d218fb5bb2c6fd6fd3a88 Mon Sep 17 00:00:00 2001
From: Joel E. Denny <jdenny <at> clemson.edu>
Date: Tue, 15 Dec 2009 18:56:52 -0500
Subject: [PATCH] autoconf: update to latest for fix of M4 detection.

Reported by Eric Blake.
* submodules/autoconf: Update.
---
 ChangeLog           |    6 ++++++
 submodules/autoconf |    2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Krohm | 30 Dec 01:03
Picon
Favicon

%prec using undefined token

Hello,

I was debugging shift/reduce conflicts in a grammar and tracked
down the problem to a typo. I had misspelled a token name in a
%prec directive. The misspelled token name was an undefined token.
Like so:

%token INT
%left '-'
%left UMINUS

%%

expr: term
    | expr '-' expr
    | '-' expr %prec UNINUS
    ;

term: INT
    | '(' expr ')'
    ;

bison 2.4.1 was silent about it even with --warnings=all

It would be consistent to issue an error about this situation.
After all one cannot use an undefined token elsewhere in a rule.
So why should this be allowed in %prec?

	Florian
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joel E. Denny | 30 Dec 06:41
Favicon

Re: %prec using undefined token

On Tue, 29 Dec 2009, Florian Krohm wrote:

> I was debugging shift/reduce conflicts in a grammar and tracked
> down the problem to a typo. I had misspelled a token name in a
> %prec directive. The misspelled token name was an undefined token.
> Like so:
> 
> %token INT
> %left '-'
> %left UMINUS
> 
> %%
> 
> expr: term
>     | expr '-' expr
>     | '-' expr %prec UNINUS
>     ;
> 
> term: INT
>     | '(' expr ')'
>     ;
> 
> bison 2.4.1 was silent about it even with --warnings=all
> 
> It would be consistent to issue an error about this situation.
> After all one cannot use an undefined token elsewhere in a rule.
> So why should this be allowed in %prec?

Thanks for the report.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Joel E. Denny | 30 Dec 10:57
Favicon

Re: %prec using undefined token

On Wed, 30 Dec 2009, Joel E. Denny wrote:

> The patch below restores the complaint (as an error not a warning) for the 
> case when a %prec symbol is not defined, but it maintains the complaint 
> for the case when the symbol is a nonterminal.  This patch might break 
> compatibility with Bison 2.4 and 2.4.1.  I'm trying to decide if I should 
> rewrite it to be a warning in Bison 2.4.2 but an error in Bison 2.5 and 
> later.

I've decided I should, and I've found an easy way to do it.  I'm planning 
to push the first patch below to branch-2.4.2.  I'm planning to push both 
patches below to branch-2.5 and master.  I'll wait a little for comments.

>From 293185465c93e0e4818ea738b655dd9bace49a7c Mon Sep 17 00:00:00 2001
From: Joel E. Denny <jdenny <at> clemson.edu>
Date: Wed, 30 Dec 2009 03:20:11 -0500
Subject: [PATCH] POSIX: warn if %prec's token was not defined.

Reported by Florian Krohm at
<http://lists.gnu.org/archive/html/bug-bison/2009-12/msg00005.html>.
* NEWS (2.4.2): Document.
* src/reader.c (grammar_rule_check): Implement.
(grammar_current_rule_prec_set): Add comments explaining that we
here assume a %prec identifier is a token, but we still manage
to support POSIX.
* tests/input.at (%prec's token must be defined): New test
group.
---
 ChangeLog      |   13 +++++++++++++
 NEWS           |   10 ++++++++++
(Continue reading)

Permalink | Reply | 2 comments |
headers
Florian Krohm | 30 Dec 18:02
Picon
Favicon

Re: %prec using undefined token

On Wednesday 30 December 2009 12:41:46 am Joel E. Denny wrote:
> 
> Thanks for the report.
> 

Thanks for the fix.

It'd be helpful for debugging grammars to have a warning that is triggered
when a name is referred to that is not explicitly declared as non/terminal.
That's less cumbersome than digging through the report file.
Perhaps something to consider for the next version.

	Florian
Permalink | Reply | 2 comments |

Gmane