CAPL 踩坑记录：十六进制版本号解析出现“累加”Bug——局部变量一定要显式清零！
摘要：在 CANoe 里用 CAPL 解析
0x000F / 0x07 / 0x0000三个软件版本号预期值，结果却解析成15 / 3847 / 252116992。排查发现是ParseHex的累加器变量在多次函数调用之间残留了上一次的结果，根因是 CAPL 局部变量“声明处初始化”不可靠。本文记录现象、定位过程与修复，并总结一条重要避坑经验：CAPL 里的累加器/解析器，务必在函数体内显式清零。
一、现象
压测脚本里，多个模块的软件版本号预期值是 string 类型（面板可输入 0x0001 这样的十六进制），CAPL 用自定义 ParseHex 把字符串解析成整数，再和 CAN 信号里读到的实际版本号比较。
某次我在面板里分别设定：
| 变量 | 设定值 | 期望解析结果 |
|---|---|---|
VerNum_Exp_A |
0x000F |
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/sinat_40003796/article/details/169355425
