为何vsprintf()会对8位数字移位？基于Keil Cx51与EFM8 MCU的疑问

这确实是字节序结合Keil Cx51的参数传递规则导致的问题，我之前在8051平台开发时也踩过类似的坑，下面给你拆解清楚：

核心原因：参数提升+调用约定的字节顺序差异 #

1. Cx51的默认参数提升逻辑
   在C语言中，向vsprintf这类变参函数传递小于int的类型（比如unsigned char）时，会触发默认参数提升。由于EFM8是8051内核，int是16位类型，所以8位的unsigned char会被提升为16位的unsigned int。但Keil Cx51在这里的处理很特殊：它会把原8位值放到16位值的高字节，低字节自动补0，而不是常规的零扩展到低字节。也就是说，你传递的unsigned char 1（0x01）会被处理成16位的0x0100，而不是预期的0x0001。

2. vsprintf的格式解析规则
   当你使用%d格式符时，vsprintf会从参数列表中读取两个字节来组成16位的int值，并且是按先读的字节作为高字节的方式组合。所以当Cx51传递过来的是0x01（第一个字节）和0x00（第二个字节）时，vsprintf会把它们组合成0x01 << 8 | 0x00 = 256，这就是你看到的结果。

为什么强制类型转换后正常？ #

当你显式把参数强制转换为int（比如(int)1）时，相当于告诉编译器直接生成标准的16位int值0x0001。此时Cx51会按标准的参数传递规则，把低字节0x00和高字节0x01依次传入参数列表，vsprintf读取后组合成0x0001，也就是你预期的1。

总结&解决方法 #

本质上这是8位MCU编译器的特殊调用约定和变参函数解析逻辑之间的不匹配，并非传统意义上的内存字节序问题，但和字节传递顺序直接相关。解决方法很简单：

• 向vsprintf、printf这类变参函数传递8位类型参数时，一定要显式强制转换为int或unsigned int，确保参数按标准16位值传递，避免解析错误。

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