Re: Stack overflow

>>> "Paul" == Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

 > Waldek Hebisch <hebisch <at> math.uni.wroc.pl> writes:
 >> bison-2.1 fails to detect stack overflow in GLR parser.

 > 	* data/glr.c (yyexpandGLRStack): Catch an off-by-one error that
 > 	led to a segmentation fault in GNU Pascal.  Problem reported
 > 	by Waldek Hebisch.

How come GNU Pascal wishes to use GLR?  I thought Pascal's syntax was
clean.

Problem, migration from bison1.34 to later versions

I am new to Bison, and I was using Bison1.34. The project I worked on
was working well.
but when I tried to use later versions of Bison "Bison1.50 1.875 2.0
2.1" all of them failed to generate the right output. I tried to trace
the Bison behaviour during execution and I found out that it passes
worng tokens in some times, and in other times it was unexpected.
I am working under LinuxRedhat 9 using and updated versionof Flex.
I have already installed GNU M4 v1.4.4.

--
Mahmoud A. Gomaa

Re: Stack overflow

> >>> "Paul" == Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
> 
>  > Waldek Hebisch <hebisch <at> math.uni.wroc.pl> writes:
>  >> bison-2.1 fails to detect stack overflow in GLR parser.
> 
>  > 	* data/glr.c (yyexpandGLRStack): Catch an off-by-one error that
>  > 	led to a segmentation fault in GNU Pascal.  Problem reported
>  > 	by Waldek Hebisch.
> 
> How come GNU Pascal wishes to use GLR?  I thought Pascal's syntax was
> clean.
> 

Clean syntax is long forgotten. Look at Extended Pascal standard (ISO-10206)
and at Borland Delphi. Both have large and hairy grammars. Especially
Borland add a bunch of constructs that are pretty tricky to parse. 
GNU Pascal wants to compatible to both of them (and to a few less popular
dialects). So GNU Pascal accepts legal constructs of _both_ dialects,
but keeps as reserved words only original Pascal reserved words. For
details look at GNU Pascal manual, internals part contains nice examples
of constructs which are beyond capabilities of LL(1) and LR(1) parsers.

Using GLR has both advantages (grammar is simpler and handles more
constructs than old non-GLR grammar) and disadvantages (debugging
parser is harder), but the balace is very positive.

--

-- 
                              Waldek Hebisch
hebisch <at> math.uni.wroc.pl 

Per-type %destructor?

Hi everybody,

I've just picked up bison 2.1, and I read in the manual that feedback on 
the %destructor feature was wanted. I do have one issue with the way it 
is implemented, and I didn't find any discussions in the archives that 
mentioned this, so here I am to report. If this has already been 
resolved or rejected earlier, please forgive my ignorance. 

My issue with the 2.1 %destructor feature is that destructors are only 
specifiable on a per-symbol basis, while I would like to specify them 
per *type*. I am building a parser that simply generates an AST, using 
something like this:

%union {
    Element *elem;
    SomeOtherType *blah;
}

%type <elem> almost all of my symbols go here
%type <blah> a couple of symbols go here

All of the elem types are "owned" by their tokens, while the blah types 
are *not* the owners of the SomeOtherType objects that the blah value 
points to. So I would like to specify something like:

%destructor <elem> { delete $$; }

And leave the <blah>-typed symbols without a destructor. But no, I 
apparently have to specify:

Re: Per-type %destructor?

On Sat, 8 Apr 2006, Bart Samwel wrote:

> I've just picked up bison 2.1, and I read in the manual that feedback on the
> %destructor feature was wanted. I do have one issue with the way it is
> implemented, and I didn't find any discussions in the archives that mentioned
> this, so here I am to report. If this has already been resolved or rejected
> earlier, please forgive my ignorance. 
> 
> My issue with the 2.1 %destructor feature is that destructors are only
> specifiable on a per-symbol basis, while I would like to specify them per
> *type*.

This has been discussed briefly before, and I agree with you.  At least 
one other developer agreed at the time, and there were no objections, so I 
think it will happen eventually.

Thanks for the feedback.

Joel

Re: Per-type %destructor?

Hi Joel,

Joel E. Denny wrote:
> On Sat, 8 Apr 2006, Bart Samwel wrote:
> 
>> I've just picked up bison 2.1, and I read in the manual that feedback on the
>> %destructor feature was wanted. I do have one issue with the way it is
>> implemented, and I didn't find any discussions in the archives that mentioned
>> this, so here I am to report. If this has already been resolved or rejected
>> earlier, please forgive my ignorance. 
>>
>> My issue with the 2.1 %destructor feature is that destructors are only
>> specifiable on a per-symbol basis, while I would like to specify them per
>> *type*.
> 
> This has been discussed briefly before, and I agree with you.  At least 
> one other developer agreed at the time, and there were no objections, so I 
> think it will happen eventually.

Great! I'll start using the feature as it is then, and migrate to the 
"typewide" version when it appears.

> Thanks for the feedback.

Thanks for making my life easier. 

Cheers,
Bart

Re: Problem, migration from bison1.34 to later versions

"Mahmoud A. Gomaa" <mahmoud.gomaa <at> gmail.com> writes:

> I am new to Bison, and I was using Bison1.34. The project I worked
> on was working well but when I tried to use later versions of Bison
> "Bison1.50 1.875 2.0 2.1" all of them failed to generate the right
> output.

Have you tried Bison test version 2.1a?  It fixes some backward
compatibility bugs.

ftp://alpha.gnu.org/gnu/bison/bison-2.1a.tar.gz

If 2.1a doesn't work for you, can you please email a test case
illustrating the problem to bug-bison <at> gnu.org?

Thanks.

Re: Bison yacc.c

twlevo <twlevo <at> xs4all.nl> writes:

> in yacc.c line 558 noticed possibly better to have
> #define YYEMPTY (-2)
> #define yyclearin (yychar = YYEMPTY)

I assume you mean a patch like this:

--- old/yacc.c	2006-03-12 06:45:27.000000000 -0800
+++ new/yacc.c	2006-04-09 00:15:10.000000000 -0700
@@ -554,8 +554,8 @@ static const ]b4_int_type_for([b4_stos])
 };

 #define yyerrok		(yyerrstatus = 0)
-#define yyclearin	(yychar = YYEMPTY)
 #define YYEMPTY		(-2)
+#define yyclearin	(yychar = YYEMPTY)
 #define YYEOF		0

 #define YYACCEPT	goto yyacceptlab
#define yyclearin	(yychar = YYEMPTY)

I don't think this is needed, since the rules about expansion of
#define are quite standard.

> ps. how about a bison-2.1b test version

We're trying to generate Bison 2.2.  At this point the only holdup is
the licensing wording.

[GNU Bison 2.1] testsuite: 5 39 40 41 42 43 44 45 48 49 51 62 63 64

To: <bug-bison <at> gnu.org>
   Subject: [GNU Bison 2.1] testsuite: 5 39 40 41 42 43 44 45 48 49 51 62 
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 
88 89 96 97 98 99 100 104 111 112 115 116 120 121 122 123 124 125 126 127 
128 129 130 131 132 133 134 135 failed

O/S: Solaris 2.8

-----------------------------------------------
   Karl Burkett            burkett <at> rice.edu
    Rice University        713.348.6256
-----------------------------------------------

## ------------------------- ##
## GNU Bison 2.1 test suite. ##
## ------------------------- ##

testsuite: command line was:
  $ ./testsuite 

## ----------- ##
## ChangeLogs. ##
## ----------- ##

testsuite: ../ChangeLog:
| 2005-09-16  Paul Eggert  <eggert <at> cs.ucla.edu>
| 
| 	* NEWS: Version 2.1.
| 

Re: [GNU Bison 2.1] testsuite: 5 39 40 41 42 43 44 45 48 49 51 62 63 64

Thanks for the bug report.  All the failures seem to be due failures like this:

  ./testsuite: line 1351: gcc: command not found

Can you verify why that might have happened?  For example, is gcc in
your PATH?

Also, if you have the time, can you please try the latest beta test version?
It has some fixes in the area of identifying compilers.

ftp://alpha.gnu.org/gnu/bison/bison-2.1a.tar.gz

Thanks.