Bison中yypush_parse()执行后访问YYSTYPE的异常问题求助

兄弟，我之前也踩过类似的坑，Bison的YYSTYPE值确实经常让人摸不着头脑，尤其是你这种明明没设置过却出现奇怪数值的情况。先给你拆解下可能的原因和排查方向：

• 先纠正一个常见误解：Bison并不会自动保留「最后执行的动作」生成的值，最终YYSTYPE里存的其实是顶层起始规则的$$值。如果你的顶层规则没写动作，Bison会默认把最后一个符号的$n值赋给$$，但这个“最后一个符号”未必是你以为的最后执行的那个动作结果。

• 关于49这个值的猜测：49刚好是ASCII字符'1'的编码，你说排除了最后字符的ASCII，那大概率是某个你没留意到的规则动作里显式赋值的。比如有没有某个不起眼的小规则（比如匹配数字、标记符的规则）里，不小心写了$$ = 49;？或者本来想返回规则索引，结果因为计数从1开始，48条规则的最后一条索引加1就成了49？

• 具体排查步骤：

  • 先盯紧你的顶层起始规则：比如如果你的起始规则是start: expr_list，那看看有没有给它加动作{ $$ = $1; }，确保最终传递的是你想要的结果。如果没加动作，Bison会默认取expr_list的最后一个子符号的值，这很可能不是你要的。
  • 开启Bison调试模式：编译解析器时加上-t参数，运行时会输出每一步的规则匹配、动作执行细节，以及$$的赋值过程，跟着日志一步步找，肯定能看到49是在哪一步被塞进去的。
  • 全局搜索所有规则的动作：检查有没有任何地方直接给$$或者YYSTYPE相关变量赋值成49的情况，哪怕是笔误（比如把'1'写成了49，或者计算时出错）。
  • 排查未初始化的情况：如果YYSTYPE用的是默认int类型，有没有可能是某个未初始化的临时变量被误写入？不过49是个确定值，这种概率比较低，但也可以排查下。

内容的提问来源于stack exchange，提问作者wvxvw