headers
Alexandre Duret-Lutz | 1 Aug 16:06
X-Face
Picon
Favicon

header guards in lalr1.cc (bison 2.3)

Hi folks!

The library I'm working on contains several lalr1.cc parsers
calling each others.  Each parser has its own, unique, %name-prefix.

In the current implementation, using %name-prefix sets the
namespace for the classes location and position as well as the
for parser itself.

My problem is that one of my parser needs to handle the
locations of another parser as well as its own.  So
basically it should include the "location.hh" generated by
Bison for the two parsers.  Unfortunately both files start with
the same guard :

| #ifndef BISON_LOCATION_HH
| # define BISON_LOCATION_HH

Likewise for position.hh.  So I have to insert some unpleasant
"#undefine BISON_LOCATION_HH" and "#undefine BISON_POSITION_HH"
at some point between the two inclusions.  Yuck.

I'd like to suggest two ways to improve bison in this area :

1) Do not use hard-coded headers.  
   Any reason all these guards can't use b4_namespace?

2) Provide a way to control the namespace in which the classes
   position and location are defined.  Since all these classes
   are identical, I see no reason to define them in different
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hans Aberg | 2 Aug 08:51
Picon
Picon

Re: header guards in lalr1.cc (bison 2.3)


On 1 Aug 2006, at 16:06, Alexandre Duret-Lutz wrote:

> Hi folks!
>
> The library I'm working on contains several lalr1.cc parsers
> calling each others.  Each parser has its own, unique, %name-prefix.
>
> In the current implementation, using %name-prefix sets the
> namespace for the classes location and position as well as the
> for parser itself.
>
> My problem is that one of my parser needs to handle the
> locations of another parser as well as its own.  So
> basically it should include the "location.hh" generated by
> Bison for the two parsers.  Unfortunately both files start with
> the same guard :
>
> | #ifndef BISON_LOCATION_HH
> | # define BISON_LOCATION_HH
>
> Likewise for position.hh.  So I have to insert some unpleasant
> "#undefine BISON_LOCATION_HH" and "#undefine BISON_POSITION_HH"
> at some point between the two inclusions.  Yuck.

My guess is that these header guards ought to include the %name- 
prefix name somehow.

Similarly, %name-prefix name ought to be used to create a suitable C+ 
+ 'namespace'.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Eggert | 6 Aug 08:21
Favicon

Re: Fwd: %token QUOTE "\""

Frans Englich <frans.englich <at> telia.com> writes:

> (Is there a reason why the documentation hasn't been updated for Bison 2.2? 
> http://www.gnu.org/software/bison/manual/html_mono/bison.html mentions 2.1.)

Hadn't thought of it.  Thanks for reminding me.  It's updated now.
Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 8 Aug 22:14
Picon
Picon

typos

Hello bug-bison readers,

I've found some typos in the CVS bison documentation, see the patch
below.  Please check whether the YYPRINTF is really a typo; if yes,
it would be good to regenerate the LocalWords: list afterwards.

Cheers,
Ralf

	* doc/bison.texinfo: Fix some typos.

Index: doc/bison.texinfo
===================================================================
RCS file: /cvsroot/bison/bison/doc/bison.texinfo,v
retrieving revision 1.199
diff -u -r1.199 bison.texinfo
--- doc/bison.texinfo	29 Jul 2006 05:53:41 -0000	1.199
+++ doc/bison.texinfo	8 Aug 2006 20:12:15 -0000
@@ -2635,7 +2635,7 @@
 don't need any C declarations, you may omit the @samp{%@{} and
 @samp{%@}} delimiters that bracket this section.

-The @var{Prologue} section is terminated by the the first occurrence
+The @var{Prologue} section is terminated by the first occurrence
 of @samp{%@}} that is outside a comment, a string literal, or a
 character constant.

@@ -6764,7 +6764,7 @@
 @var{format} and @var{args} are the usual @code{printf} format and
 arguments.  If you define @code{YYDEBUG} to a nonzero value but do not
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Eggert | 9 Aug 19:16
Favicon

Re: typos

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> I've found some typos in the CVS bison documentation, see the patch
> below.

Thanks for reporting this.

> Please check whether the YYPRINTF is really a typo; if yes,
> it would be good to regenerate the LocalWords: list afterwards.

It was a typo, but I don't know how to generate or use that LocalWords
list.  (Does anybody else know?)  I fixed it by hand before checking in.

Here's what I installed:

2006-08-09  Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>  (tiny change)

	* doc/bison.texinfo: Fix some typos.

--- doc/bison.texinfo	29 Jul 2006 05:53:41 -0000	1.199
+++ doc/bison.texinfo	9 Aug 2006 17:13:46 -0000	1.200
@@ -2635,7 +2635,7 @@ they precede the definition of @code{yyp
 don't need any C declarations, you may omit the @samp{%@{} and
 @samp{%@}} delimiters that bracket this section.

-The @var{Prologue} section is terminated by the the first occurrence
+The @var{Prologue} section is terminated by the first occurrence
 of @samp{%@}} that is outside a comment, a string literal, or a
 character constant.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elie Roux | 10 Aug 14:41
Picon
Picon

bison french translation

Hello,

I have corrected the bison 2.3 translation in french (my translation is 
based on the template 
ftp://ftp.unex.es/pub/gnu-i18n/po/teams/PO/fr/bison-2.3.fr.po). If this 
list was not the good one to send it, please tell me where to send it.

Thanks by advance,
--

-- 
Elie
Attachment (bison-2.3-fr.po.gz): application/x-gzip, 6501 bytes
Permalink | Reply | 1 comment |
headers
Paul Eggert | 10 Aug 19:06
Favicon

Re: bison french translation

Elie Roux <elie.roux <at> enst-bretagne.fr> writes:

> I have corrected the bison 2.3 translation in french (my translation
> is based on the template
> ftp://ftp.unex.es/pub/gnu-i18n/po/teams/PO/fr/bison-2.3.fr.po). If
> this list was not the good one to send it, please tell me where to
> send it.

Please send it to the Last-Translator and Language-Team email
addresses listed in po/fr.po, namely:

Michel Robitaille <robitail <at> IRO.UMontreal.CA>,
French <traduc <at> traduc.org>

Thanks for fixing this.
Permalink | Reply | 0 comments |
headers
zdprikryl | 18 Aug 09:41
Picon
Favicon

Bison can not create LR table

Hello,
If I write grammar like below, than bison prints this:

conflicts: 1 reduce/reduce
warning: rule never reduced because of conflicts: ireg_MOVE_INDIRECT_A: ireg
warning: rule never reduced because of conflicts:
ireg_MOVE_INDIRECT_DATA: ireg

But grammar is LR for sure, because I can construct it by hand on paper.

Thanks

ZP

--------
Grammar:
--------

MOVE_INDIRECT_DIRECT: "MOV" "@" "R" ireg_MOVE_INDIRECT_DIRECT ","
dir_MOVE_INDIRECT_DIRECT
                      {
                      ...
                      };
MOVE_INDIRECT: "MOV" "@" "R" ireg_MOVE_INDIRECT_A "," "A"
                {
                ...
                };
MOVE_INDIRECT_DATA: "MOV" "@" "R" ireg_MOVE_INDIRECT_DATA "," "#"
data_MOVE_INDIRECT_DATA
                {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sander Brandenburg | 27 Aug 19:31
Picon

calc++ example leaks

Hi,

I encountered memory leaks in the calc++ example from the bison manual. I
verified it on the calc++ example that's in the bison-2.3 tarball.

Below is a fix for the memory leaks. I'm only not sure the way I solve it is
good practice, because keeping track of what needs to be deleted looks
rather cumbersome.

Cheers,
Sander Brandenburg

diff -r -u calc++-orig/calc++-parser.yy calc++/calc++-parser.yy
--- calc++-orig/calc++-parser.yy        2006-08-27 19:17:19.000000000 +0200
+++ calc++/calc++-parser.yy     2006-08-27 19:20:05.000000000 +0200
@@ -52,7 +52,7 @@
 assignments: assignments assignment {}
            | /* Nothing.  */        {};

-assignment: "identifier" ":=" exp { driver.variables[*$1] = $3; };
+assignment: "identifier" ":=" exp { driver.variables[*$1] = $3; delete $1;
};

 %left '+' '-';
 %left '*' '/';
@@ -60,7 +60,7 @@
    | exp '-' exp   { $$ = $1 - $3; }
    | exp '*' exp   { $$ = $1 * $3; }
    | exp '/' exp   { $$ = $1 / $3; }
-   | "identifier"  { $$ = driver.variables[*$1]; }
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Deutschmann | 20 Aug 08:57

[GNU Bison 2.3] testsuite: 103 104 failed

I've experienced some test failures after compiling bison 2.3, #103 and
#104.

I've investigated and found the cause.  The parser skeleton uses a local
version of the stpcpy() function, which is not standard but is present in
GLIBC, which only declares it if _GNU_SOURCE is defined.

The code tries to be clever and detect this circumstance automatically,
replacing the local yystpcpy() function with a reference to stpcpy() if
GLIBC is in use and _GNU_SOURCE is defined.  This avoids unneeded
namespace pollution, but takes advantage if the programmer already set
_GNU_SOURCE in his prologue region (between %{ and %}).

The trouble is, the C++ parser includes library headers before including
the prologue region.  After the first library header is loaded, the
setting of _GNU_SOURCE and related macros becomes effectively locked --
changing them will have no effect on what functions are declared.

So if _GNU_SOURCE is defined in the prologue of the .y file, it will have
no effect on the GLIBC headers.  But it will still be defined, fooling the
parser skeleton into assuming _GNU_SOURCE is in effect and stpcpy() is
available.

The code in tests #103/#104 effectively includes _GNU_SOURCE in the
headers (via "config.h").  The resulting C++ code attempts to use stpcpy()
without a declaration.  GCC makes incorrect assumptions about stpcpy()'s
argument and return types, and then refuses to compile the parser due to
typing violations.

Altering 'glr.c' to always use a local yystpcpy() allows all tests to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane