C语言运算符优先级问题：单行与拆分表达式计算结果不一致

两个版本计算结果不一致的核心原因是C语言整型提升规则导致的类型截断时机差异，和浮点数运算精度无关。

关键规则说明 #

C语言中所有秩低于int的整数类型（比如unsigned char、16位SHORT）在参与移位、算术运算前，都会自动提升为int类型（当前主流32/64位环境下int为32位长度）再计算，运算过程中不会保留原短类型的位宽；只有赋值给对应短类型变量、或对表达式整体做短类型强制转换时，才会触发位截断，按短类型的编码规则解释数值。
你的代码中SHORT为16位有符号短整型，data数组元素为unsigned char（8位无符号），两个版本的计算流程差异如下：

错误单行版本的计算流程 #

1. 子表达式(SHORT)data[9]先将8位无符号的数组元素转为16位有符号值，但在执行<<8移位操作前，会被自动提升为32位int，移位后的结果是32位int类型，不是预期的16位SHORT。
2. 子表达式data[8]参与加法前同样被提升为32位int，和移位结果相加后，整个括号内的结果是32位int类型，全程没有任何截断操作。
3. 举实际值为例：若data[9]=0xFF、data[8]=0x70，括号内计算结果为32位值0x0000FF70，对应十进制正数65392，而非预期的16位有符号值-144。用这个大正数参与后续浮点计算，自然会得到远高于正常值的错误结果。

正确拆分版本的计算流程 #

1. 括号内的计算逻辑和单行版本完全一致，先得到32位int结果0x0000FF70（65392）。
2. 赋值给SHORT类型变量ee时，会触发类型截断：仅保留低16位，按16位有符号规则解释为0xFF70，对应十进制值-144，和传感器原始数值的预期解析结果一致。
3. 用正确的ee值参与后续浮点计算，结果自然正常。

修复方法 #

不需要拆分语句，只要对括号内的整体整数表达式加SHORT强制转换，手动触发截断即可：

float tmp = 26.75 + (SHORT)(data[8] + (((SHORT) data[9]) << 8)) * 0.125 / 64;

测试结果参考 #

内容的提问来源于stack exchange，提问作者gustav.b