Re: Possible bug or simple nuisance compiler warning

> 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" <[email protected]> 
To: "Jot Dot" <[email protected]> 
Cc: [email protected] 
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 <[email protected]> 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!