深度报告：消失的头文件与 ABI 的背叛
案卷编号： 0xDEADC0DE 技术背景： 搭载硬件 FPU（浮点运算单元）的 ARM Cortex-M4F 内核 核心矛盾： 编译器在“盲目状态”下对函数调用契约（Calling Convention）的脑补。
第一幕：编译器的“脑补”契约
当侦探 A 删掉 #include <math.h> 时，编译器进入了 C89 兼容模式。
在 C 语言的古老法律中，有一条被称为“隐式声明”的条文：
“凡是未曾谋面的函数，一律视为返回
int类型，且接收任意数量的参数。”
于是，编译器在处理 actualTempVal = (... - sqrt(disc)) / ... 这行代码时，内心的剧本是这样的：
- “哦，有个叫
sqrt的家伙，没见过。按规矩，它肯定返回一个 32 位的整数（int）。” - “既然返回的是整数，根据 Procedure Call Standard (PCS)，结果一定会出现在通用寄存器 R0 中。”
- “我要把这个 R0 里的‘整数’转换成浮点数，再进行后面的减法。”
第二幕：ABI 的“死亡错位”
然而，在另一个房间里，数学库（libm.a）中的 sqrtf 正在辛勤工作。
这个函数是按照 Hard-float ABI（硬浮点规则） 编译的：
- 它计算出了
12.75的平方根3.57。 - 作为一个遵守硬浮点契约的函数，它神圣地将结果存入了 浮点寄存器 S0。
- 然后，它潇洒地执行了
BX LR（返回），留下一脸懵逼的调用者。
案发现场重现：
- 数学库： “结果我放 S0 寄存器里了，你自便。”
- 主程序： “收到，我去 R0 寄存器里取那个‘整数’。”
此时的 R0 寄存器里存的是什么？它是之前执行 4 * ts22 * (...) 乘法运算时留下的残余数据，或者是某个临时变量的地址。主程序把它当成了一个 int 取了出来。
第三幕：位模式（Bit-pattern）的灵魂扭曲
为什么侦探 A 看到的 Root*100 总是 2400？
在底层，这涉及到浮点数与整数的强制转换陷阱。
假设 R0 里的残留值是某个十六进制数（例如上一次运算留下的 0x4019999A）。
- 主程序误判： “R0 里的值是
0x4019999A，它是个整数！” - 强制转换： 主程序执行了一行隐形的汇编指令
VCVT.F32.S32 S1, R0（将整数 R0 转换为浮点数 S1）。 - 结果： 这个转换过程完全破坏了数据原始的物理意义。那个原本代表某个浮点数的二进制序列，被粗暴地解释成了一个巨大的整数，再转回浮点数时，就变成了那个诡异的固定的
2400。
第四幕：链接器的“沉默共犯”
有人会问：“既然编译器搞错了，为什么链接（Link）的时候没发现？”
这是 C 语言最危险的设计缺陷之一：符号修饰（Symbol Mangling）的缺失。
- 在 C++ 中，
sqrt会根据参数类型被修饰成_Z4sqrtf这样带有特征的名字。如果找不到对应的函数，链接器会立即报错。 - 在 C 语言中，函数名就是它的唯一 ID。链接器只负责寻找名为
sqrt的内存地址。它找到了数学库里的sqrt接口，却并不关心这个接口要求的**寄存器契约（S0）和主程序预期的寄存器契约（R0）**是否匹配。
链接器心想： “名字对上了就行，至于你们怎么传参、怎么接结果，那是你们俩的事。”
第五幕：判决书
这场事故的元凶并非代码逻辑，而是 “编译单元间的信息不对称”。
- 由于没有头文件，编译器被迫对函数原型进行“自杀式猜想”。
- 由于 ABI 的多样性，同一个数据在不同类型的寄存器（通用寄存器 vs 浮点寄存器）之间玩起了消失。
- 由于 C 链接机制的简陋，这种致命的类型不匹配逃过了链接阶段的审查。
侦探的最后忠告：
不要相信编译器能猜透你的心思。当你省掉一行的 #include 时，你其实是拆掉了连接 CPU 两个不同世界的桥梁，让你的数据坠入了寄存器之间的无底深渊。
结案： 建议开启编译器选项 -Werror=implicit-function-declaration。在现代工程中，任何隐式声明都应该被视为最高级别的恐怖袭击。