> Have you looked at the examples in examples/c++?
Yes. I can't see anything I'm doing different in that respect. btw: I've been
aware of lex/yacc for about 40 years (I'm a fossil) but, up till now, preferred
hand coding recursive decent parsers.
> What do you mean by "I added a second error token into a rule"? Could you
> please show that rule?
** snip **
%start start-rule
%%
start-rule:
{ scanner.yyout << "Version 0.0.1\n\n"; }
stmts
{ scanner.yyout << "\n\n*** END\n"; }
| error// { scanner.yyout << scanner.loc.begin.line << ':' <<
scanner.loc.begin.column << " Syntax Error\n"; }
/* ^^^^^ First occurance. btw docs refer to this as an error token. */
;
stmts:
proc_decl
| CONST_ const_decl
** snip **
const_decl:
single_const_decl { $$ = $1; }
| const_decl ';' single_const_decl { $$ = result.makeConstList($1, $3); }
;
single_const_decl:
IDENTIFIER '=' expr { $$ = result.makeConstant($1, $3); }
/* ^^^^^ Second one causes the issue. Remove it and no warning */
;
> The definition of state_type depends on the grammar. What is your definition?
It's what ever the default is? I haven't modified it:
/// Stored state numbers (used for stacks).
typedef signed char state_type;
Ahhh!!. I see, by putting in the second error token in the rule, the definition
for yytable_ changes from an initial
static const signed char
to:
static const short
where state_type remains as:
typedef unsigned char state_type;
Hmm.. a return value of unsigned char but
if (0 <= yyr && yyr <= yylast_ && yycheck_[yyr] == yystate)
return yytable_[yyr]; <<<< const signed char (1 error in rule) vs const short
(2 error in 2 rules)
else
return yydefgoto_[yysym - YYNTOKENS]; <<<<< ******* const signed char both
tests *******
There ya go.
1) First of all, yydefgoto is signed vs return value of unsigned (potential
no-no). I hope the table is widened after 127 not 255, Might be an issue.
2) Definitely when we go to a short for yytable but then casting to unsigned
char - that could have side effects. Unless the table is limited to 256
entries.
No point in widening the yytable entries unless the state_type definition
changes. yydefgoto_ defn can be potentially a problem too.
I think this is a possibility of a bug happening here. Just my luck. Things
like this just always happen to follow me around.
Well, my 1% odd feeling was onto something but the problem posted in help-bison
is still there (I've removed the second error token so not to get a warning.)
Thanks for your time with this.
From: "Akim Demaille" <a...@lrde.epita.fr>
To: "Jot Dot" <jot...@shaw.ca>
Cc: bug-bison@gnu.org
Sent: Thursday, November 26, 2020 11:55:31 PM
Subject: Re: Possible bug or simple nuisance compiler warning
Hi Jot,
> Le 27 nov. 2020 à 02:15, Jot Dot <jot...@shaw.ca> a écrit :
>
> While beating my head senseless trying to get my first flex/bison (c++ style)
> project going,
Have you looked at the examples in examples/c++?
> I try to catch some error tokens inside my bison rules to aid me by supplying
> diagnostic output.
> I added a second error token into a rule to debug an issue I'm trying to
> figure out (which I posted in help-bison).
I have not received your message on help-bison
(https://lists.gnu.org/r/help-bison/).
What do you mean by "I added a second error token into a rule"? Could you
please show that rule?
> 1>D:\data\c\FlexBisonLoader\My_Parser\parser.cpp(454,26): warning C4244:
> 'return': conversion from 'const short' to 'gen::Parser::state_type',
> possible loss of data
>
> The following snippet of code in the generated .cpp source file:
> Parser ::state_type
> Parser ::yy_lr_goto_state_ (state_type yystate, int yysym)
> {
> int yyr = yypgoto_[yysym - YYNTOKENS] + yystate;
> if (0 <= yyr && yyr <= yylast_ && yycheck_[yyr] == yystate)
> return yytable_[yyr];
> else
> return yydefgoto_[yysym - YYNTOKENS]; <<<<<<<< Warning.
> }
>
> Now this is probably just a nuisance message that can be safely ignored, but
> I wanted to bring it up to your attention.
> IMO the return value just needs to be cast to Parser::state_type.
The definition of state_type depends on the grammar. What is your definition?
> Also, when I add that extra error line, my app freezes. Now, I'm 99% sure
> this freeze is from what I'm doing, but that 1% tells me that I've never had
> this compile issue, It's a bit odd, and this parser is a state engine which
> might be in the wrong place.. etc. I've already triggered two Microsoft bugs
> in this single project / endeavour, slowing me down, so now I'm getting a bit
> paranoid.
You may want to try another compiler too :)
> Due to the odd behaviour, I figure I'd run it past you just to make sure.
Your compiler might be right. I think it's unlikely, but it's possible. To
understand why it warns, I need the definition of state_type.
Cheers!
