bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCHES] example calc++


From: Akim Demaille
Subject: Re: [PATCHES] example calc++
Date: Wed, 21 Nov 2018 17:57:10 +0100

Hi Jannick,

> Le 20 nov. 2018 à 22:20, Jannick <address@hidden> a écrit :
> 
> Hi Akim,
> 
> please see three minor patches for the example calc++ scanner.  Details in
> the attachments.

Please, stick to our style for the commit messages.  Look at a few examples, 
and imitate.

I installed the first as follows.

commit 67d77493fd16de3472c6f09b59f18946b83dfbe0
Author: Jannick <address@hidden>
Date:   Tue Nov 20 22:00:43 2018 +0100

    doc: calc++: ignore \r in the scaner
    
    * doc/bison.texi (Calc++ Scanner): Ignore \r.

diff --git a/doc/bison.texi b/doc/bison.texi
index 01d7c8dc..371cec84 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -11897,7 +11897,7 @@ Abbreviations allow for more readable rules.
 @example
 id    [a-zA-Z][a-zA-Z_0-9]*
 int   [0-9]+
-blank [ \t]
+blank [ \t\r]
 @end example
 
 @noindent



I installed the second as this:

commit 77c76338944acdd8147a5b87b8401f87b519d5f0
Author: Jannick <address@hidden>
Date:   Tue Nov 20 22:02:20 2018 +0100

    doc: calc++: remove ancient fix for flex
    
    * doc/bison.texi (Calc++ Scanner): Remove fix for Flex 2.5.31-2.5.33.

diff --git a/doc/bison.texi b/doc/bison.texi
index c3099cfc..72f28fc2 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -11821,12 +11821,6 @@ then the parser's to get the set of defined tokens.
 @comment file: calc++/scanner.ll
 @example
 address@hidden
-// Work around an incompatibility in flex (at least versions 2.5.31 through
-// 2.5.33): it generates code that does not conform to C89.  See Debian bug
-// 333231 <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>.
-# undef yywrap
-# define yywrap() 1
-
 // Pacify warnings in yy_init_buffer (observed with Flex 2.6.4)
 // and GCC 6.4.0, 7.3.0.
 #if defined __GNUC__ && !defined __clang__ && 6 <= __GNUC__




I think the third one is wrong.  yylex_destroy is for reentrant scanners, it’s 
releasing what yylex_init acquired.

We don’t use a reentrant scanner, and we don’t call yylex_init, so I don’t 
think we should call yylex_destroy.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]