为何sscanf转换十六进制字符串为数字时表现不一致？

你遇到的是C语言中未定义行为的典型表现——格式符与参数类型不匹配时，标准不保证任何固定行为，不同函数栈帧的初始状态差异导致了表现不同。

核心背景：未定义行为的本质 #

C标准明确规定：scanf系列函数的格式符必须与对应指针指向的变量类型严格匹配，printf系列函数的格式符也必须与参数类型严格匹配，否则行为完全未定义——编译器和运行时可以做出任何操作，包括看起来“正常”或者完全随机的结果。

main函数中出现随机值的原因 #

在main里，你用%x（对应unsigned int类型）去写入unsigned long long类型的num：

• sscanf会把解析出的0xff写入到&num指向的前4字节（假设是32位int的平台），但unsigned long long占8字节，剩下的4字节是栈上的残留垃圾值（未初始化的局部变量栈空间通常保留之前操作的遗留数据）。
• 后续用printf("%x", num)输出时，%x期望的是unsigned int类型参数，但你传入的是unsigned long long，这又是一次格式符不匹配的未定义行为：在不同调用约定下，printf可能错误地读取栈上或寄存器中的额外字节，导致最终输出包含那些未被覆盖的随机垃圾值。

test函数中看似“正常”的原因 #

在test函数里，所有变量都是局部栈变量，它们所在的栈区域刚好处于初始值更干净的状态（比如栈帧刚创建，未被之前的操作污染，高字节恰好为0）：

• 对于unsigned short num：sscanf写入低2字节为0xff，高2字节本来是0，所以整个变量值是0xff；printf("%x", num)时，unsigned short会被提升为unsigned int，高字节补0，输出正确。
• 对于unsigned int num2：格式符与类型完全匹配，自然输出正确。
• 对于unsigned long long num3：sscanf同样只写入低4字节为0xff，但栈上该变量的高4字节恰好是0，所以整个变量值为0xff；printf("%x", num3)时，虽然格式符不匹配，但刚好读取的低4字节是正确值，看起来输出正常。

关键总结 #

两处的差异完全是栈帧初始状态的随机巧合——未定义行为没有固定规律，今天在test里看起来正常，换个编译器版本、操作系统或者甚至只是调整局部变量的顺序，都可能让test里也出现随机值。唯一的解决方式就是严格匹配格式符与变量类型（比如用%llx处理unsigned long long）。

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