headers
Claudio Saavedra | 1 May 20:45
Picon

Re: Installing Bison from CVS

El dom, 29-04-2007 a las 13:52 +0200, Hans Aberg escribió:
> On 29 Apr 2007, at 10:25, Paul Eggert wrote:
> 
> >> I also got the following error in one of the translations module:
> >
> > You needn't worry about that; the build works just fine (it merely
> > omits the bad translation).
> 
> Right, I just reported it. In fact I only use English, and do not  
> know what they are good for :-): do they translate Bison or the  
> generated parser, for example?

At least the y.output file gets translated, too. The comments in the
generated parser don't.

Claudio

--

-- 
Claudio Saavedra <csaavedra <at> alumnos.utalca.cl>
Permalink | Reply | 6 comments |
headers
Hans Aberg | 2 May 21:34
Picon
Picon

Re: Installing Bison from CVS

On 1 May 2007, at 20:45, Claudio Saavedra wrote:

>>>> I also got the following error in one of the translations module:
>>>
>>> You needn't worry about that; the build works just fine (it merely
>>> omits the bad translation).
>>
>> Right, I just reported it. In fact I only use English, and do not
>> know what they are good for :-): do they translate Bison or the
>> generated parser, for example?
>
> At least the y.output file gets translated, too. The comments in the
> generated parser don't.

One would think that would be the most useful feature. :-) I mean, if  
one can figure out how to use Bison, one probably knows English  
well. :-)

   Hans Aberg
Permalink | Reply | 0 comments |
headers
Steve Greenburg | 11 May 14:09
Picon

problem with semantic actions

Hi,

I am implementing a parser which removes unnecessary parentheses from infix 
expressions, however I came across a very strange bug which I don't 
understand at all. My system is Fedora Core 6 with Bison 2.3 with latest 
kernel and updates as of 04/07. However I tested the same grammar file on a 
cygwin environment and got similar erroneous behavior (also Bison version 
2.3), leading me to believe the problem is either with bison or how I am 
using it. Sorry in advance if this is not a problem with bison itself, and 
also sorry for the size of the attached grammar file, but since I don't 
understand this bug I can't really make a smaller grammar file which 
reproduces it. Here is the basic grammar I had when I found the bug:

expr -> term moreterms
moreterms -> '+' moreterms | e.
term -> factor morefactors
morefactors -> '*' morefactors | e.
factor -> '(' expr ')'

To compile and run the file I enter these commands:

bison unparen.y; cc -o unparen unparen.tab.cc; ./unparen < expr

The file expr contains the following:

((((((((((1)+2)*3)+4)*5)+6)*7)+8)*9)+10)

While the semantic actions seem to successfully remove the unwanted parens, 
it replaces the '9' character with a '!' character:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Aberg | 23 May 13:15
Picon
Picon

Yacc script correct?

The Bison from CVS (Mac OS X, version 10.4.9) produces the script / 
usr/local/bin/yacc:
#! /bin/sh
exec '/usr/local/bin/bison' -y ""

Then 'yacc --version' produces:
/usr/local/bin/bison: cannot open file `': No such file or directory
And the same on other 'yacc' compiles.

What should it be?

   Hans Aberg
Permalink | Reply | 4 comments |
headers
EXCOFFIER, Denis (CS SYSTEMES INFORMATION | 23 May 13:19

erroneous yacc script


Hello,

I use bison-2.3a on a solaris 2.8 system, with the GNU make 3.81, and i found out that the generated yacc
program contains:

#! /bin/sh
exec '...my_prefix_path.../bin/bison' -y ""

instead of the (IMHO) correct

#! /bin/sh
exec '...my_prefix_path.../bin/bison' -y "$@"

Of course, with an easy modification in src/Makefile.in (line 660, replace $$@ with $$""@), i was able to
change this. However, i suspect something wrong in my configuration because i don't understand why this
had not been reported/corrected before. For example, the yacc program included in the latest cygwin
installation (built from bison-2.3 with no modification) has the correct "$@" string. Apparently, this
behaviour is there since at least bison-2.0.

Any help/inputs/pointers?

Regards.

Denis Excoffier.

This e-mail is intended only for the above addressee. It may contain privileged information.
If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. 
If you have received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the
(Continue reading)

Permalink | Reply | 1 comment |
headers
EXCOFFIER, Denis (CS SYSTEMES INFORMATION | 23 May 15:01

undocumented M4 environment variable


Hello,

I use bison-2.3a and discovered that the bison program reacts at the environment variable "M4": if it is
set, it is supposed to contain a replacement program for the compiled-in m4.

This is not indicated in the documentation, and i suggest that it must be. That way, third parties (like
maintainers of gcc-4.2.0) would find it a bad idea to install an environment variable
M4="/tmp/.../gcc-4.2.0/missing m4" in the case where m4 is not present in the $PATH during the build of
gcc-4.2.0. Currently, the result is "Broken Pipe", return code 141, no other explanation available.

By the way, i also suggest that you use the environment variable "BISON_M4" instead of the very short "M4"
for that purpose.

You may find useful to forward this to the gcc-bug list.

Regards.

Denis Excoffier.

This e-mail is intended only for the above addressee. It may contain privileged information.
If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. 
If you have received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the
recipient, for system management and security reasons. This access is controlled under Regulation of
security reasons.
This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises.
Permalink | Reply | 2 comments |
headers
darrenks | 25 May 21:06
Favicon

Ignoring %prec

Bison is ignoring %prec for this simple grammar:

%left PRIORITY2
%left PRIORITY1
%token NUMBER
%%

program : expr  { };
expr : expr '+' expr %prec PRIORITY2  { };
expr : expr '-' expr %prec PRIORITY2  { };
expr : expr '*' expr %prec PRIORITY1  { };
expr : expr '/' expr %prec PRIORITY1  { };
expr : NUMBER  { };

%%
int yyerror(char *s) {
	fprintf(stderr, "error, line %d: %s\n", yylineno, s);
	return 0;
}

int main(int argc, char **argv) {
	yyparse();
	return 0;
}

#include "lex.yy.c"

I realize a work around is to not use %prec for this, but this is not 
an option for my purposes because I am attempting to create the bison 
grammar file automatically from a format where one specifies priority
(Continue reading)

Permalink | Reply | 0 comments |
headers
darrenks | 26 May 00:36
Favicon

Ignore %prec followup

Apparently the bug I just reported is not a bug according to 
http://compilers.iecc.com/comparch/article/91-01-022

This is very unintuitive behavior and not very well documented either. 
Frankly after reading all this stuff I still do not understand how 
%prec can actually work for the unary minus example.

Sorry for the earlier false report,
Darren
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 26 May 20:19

Re: Yacc script correct?

On Wed, 23 May 2007, Hans Aberg wrote:

> The Bison from CVS (Mac OS X, version 10.4.9) produces the script /
> usr/local/bin/yacc:
> #! /bin/sh
> exec '/usr/local/bin/bison' -y ""

Thanks.  I committed the following to fix that.

Index: ChangeLog
===================================================================
RCS file: /sources/bison/bison/ChangeLog,v
retrieving revision 1.1699
diff -p -u -r1.1699 ChangeLog
--- ChangeLog	20 May 2007 05:01:53 -0000	1.1699
+++ ChangeLog	26 May 2007 18:11:54 -0000
@@ -1,3 +1,9 @@
+2007-05-26  Joel E. Denny  <jdenny <at> ces.clemson.edu>
+
+	* src/Makefile.am (yacc): Quote target action commands properly so
+	that the yacc script isn't corrupt.  Reported by Hans Aberg at
+	<http://lists.gnu.org/archive/html/bug-bison/2007-05/msg00003.html>.
+
 2007-05-20  Joel E. Denny  <jdenny <at> ces.clemson.edu>

 	Extend the front-end API for %define variables to more completely
Index: src/Makefile.am
===================================================================
RCS file: /sources/bison/bison/src/Makefile.am,v
retrieving revision 1.73
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hans Aberg | 27 May 14:57
Picon
Picon

Re: Yacc script correct?

On 26 May 2007, at 20:19, Joel E. Denny wrote:

>> The Bison from CVS (Mac OS X, version 10.4.9) produces the script /
>> usr/local/bin/yacc:
>> #! /bin/sh
>> exec '/usr/local/bin/bison' -y ""
>
> Thanks.  I committed the following to fix that.

I rebuilt it from the CVS, and now it is correct. Thanks.

Perhaps there should be new Bison development release, as the bug  
apparently is in 2.3a.

   Hans Aberg
Permalink | Reply | 0 comments |

Gmane