Hi all,
>> On 4/1/21 16:28, Stephen Taylor via Users list for the GNU Bison parser
>> generator wrote:
>>> Thanks, that seems to get around \x00 -- unfortunately, the same issue then
>>> reappears with the values \x80 - \xff … I could special case every single
>>> value e.g.
>>> \x00 {return ZE
Thanks John, but the whole point is to try to leverage the internal tables and
mechanisms that exist in Bison …. In particular the yytranslate[] table…. And
to be able to write rules that use *all* the hex codes which flex -8 is
supposed to pass along e.g.
R : ‘\x9f’ ‘\xfe’ | ‘\xff’ | ‘\x00’ ;
Thanks, that seems to get around \x00 -- unfortunately, the same issue then
reappears with the values \x80 - \xff … I could special case every single value
e.g.
\x00 {return ZERO; }
\x80 { return X80; }
\x81 { return X81; }
:
\xff { return XFF; }
. | \n { return *yytext; }
But seems a bit c
Running bison (first) with -d should produce a bison.tab.h file, that your flex
input should #include to get the definitions of %token names.
-Chris
> On Mar 30, 2021, at 1:34 PM, Stephen Taylor wrote:
>
>
> That appears to give me an error in lex:
>
> %option noyywrap
That appears to give me an error in lex:
%option noyywrap
I don’t know how you’ve set up your flex/bison interface, but I’m guessing from
your quoting that you have flex return each character as a token? Can you
special-case 0 to not have the token value 0? That is, flex does this:
\x00 { return ZERO; }
And then in your grammar:
%token ZERO
and
I am trying to parse binary files and obviously need to write rules that
include the 8-bit value 0x00 — flex appears to allow me to obtain an 8-bit
scanner using the -8 option. I seem to be able to use ‘\x01’ to ‘\xFF’ for
individual terminal symbols in Bison rules. Unfortunately, ‘\x00’ is used
