汇编中如何处理返回值小于原生寄存器位宽的Windows API

问题结论 #

这个说法完全正确，Windows API没有任何规范约定返回值位宽小于原生寄存器位宽时，会自动清零寄存器高位部分，你观测到的64位场景下RAX高位全零仅为当前实现的巧合。

具体说明 #

1. 调用约定层面的规则
   Windows 官方的x86、x64调用约定仅要求：返回值存放在对应寄存器的低位有效位部分，高位的取值完全属于未定义范畴：

• 32位x86场景下，16位/8位返回值仅保证AX/AL的取值符合预期，EAX的高位无任何约束，你遇到的ntohs高16位出现垃圾值是符合规范的，之前版本高位清零只是历史实现的额外行为，不属于必须遵守的API约定。
• 64位x64场景下的高位置零是硬件特性的附带效果：x64架构规定，任何写入32位通用寄存器的操作都会自动零扩展到整个64位寄存器，所以如果当前ntohs的实现是通过写入EAX来返回16位值，RAX高32位会自动置零。但这只是硬件层面的附带效果，不是API的承诺——如果后续系统更新修改了函数实现逻辑，高位完全可能出现非零值。

2. 最佳实践
   不管是32位还是64位代码，只要调用的函数返回值位宽小于原生寄存器位宽，都应该主动对返回寄存器做扩展处理：无符号返回值用movzx做零扩展，有符号返回值用movsx做符号扩展，和你给出的MSVC、MASM修复逻辑一致，不要依赖任何未定义的高位取值行为，避免后续系统迭代后代码出现兼容性问题。

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