WM_SIZE消息如何正确解析lParam？有符号无符号类型混用疑惑

• API宏的本质是位操作，而非类型转换：LOWORD、HIWORD这类宏的核心是直接提取参数的低16位或高16位二进制数据，不管传入参数的有符号/无符号属性。它们的实现逻辑类似(WORD)(value & 0xFFFF)，只是做二进制位的截取，而非严格意义上的类型语义转换。

• 有符号转无符号的规则是明确的，并非未定义行为：C/C++标准里，有符号整数转无符号整数的规则是按模2^N（N为目标类型位数）处理，这个是定义明确的行为。而WM_SIZE的lParam中存储的窗口宽度、高度本身就是非负数值，对应的二进制位没有符号扩展的问题——64位LPARAM的高48位都是0，所以截取低/高16位转成WORD（无符号16位）时，结果完全符合预期。

• Win32平台的兼容性约定：这些宏从16位Windows时代就存在，设计初衷就是跨位宽兼容。在64位系统中，虽然LPARAM是64位有符号类型，但WM_SIZE传递的尺寸值根本达不到需要用符号位的程度，高48位始终为0，所以无论是把LPARAM强转成DWORD（32位无符号）还是直接处理64位值，截取出来的16位结果都一致，编译器也会遵循Windows平台的约定处理这类转换，不会触发UB。

• 规范替代方案存在，但惯例用法足够安全：如果追求更严谨的类型处理，Windows提供了GET_X_LPARAM、GET_Y_LPARAM这类专门针对LPARAM的宏，它们会根据LPARAM的位宽自动适配提取逻辑。不过因为LOWORD/HIWORD的用法已经成为行业惯例，且实际场景中不会出现异常，所以大量Win32代码仍在沿用。

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