WSOCK32.DLL htons 函数答案

【问题标题】：WSOCK32.DLL htons functionWSOCK32.DLL htons 函数
【发布时间】：2018-05-08 14:55:04
【问题描述】：

在使用套接字的 Visual FoxPro 应用程序中，我们使用 wsock32.dll 并使用 htons() 函数将端口号转换为 TCP/IP 网络字节顺序。它应该返回一个介于 0 和 65535 之间的无符号短整数。使用端口 63333 进行测试时，它会返回 26103，但在安装 Windows Fall Creators 更新后，它会返回一个更大的值：16213495。

FoxPro 程序示例：

DECLARE INTEGER htons IN "wsock32.dll" INTEGER hostshort
LOCAL portNumber, htonsNumber
portNumber  = 63333
htonsNumber = htons( portNumber )
? htonsNumber

结果值应该进入 connect() 函数使用的“sockaddr”结构，但端口只有 2 个字节的空间。

有谁知道 wsock32 函数的此 Windows 更新中发生了什么和/或有解决此问题的建议？

【问题讨论】：

大致是同一个数字，0xF765F7而不是0x65F7。也许很长一段时间以来您一直在逃避错误的声明，htos() 使用 16 位无符号参数和返回值。不是整数。使用 0xFFFF 应该是一种解决方法。
它的文档显示返回值应该是无符号短整数，而不是整数。我会尝试声明短...（顺便说一句，在创作者更新中我得到 26103 没有对代码进行任何更改）。
谢谢大家。将其声明为 SHORT 会产生相同的值。计算 0xFFFF+1 时返回值的模数确实解决了现在的问题：MOD(htonsNumber, 65536) 我可能需要查看新的 IPv6 结构以备将来使用。

标签： sockets winapi visual-foxpro

【解决方案1】：

我将 Windows 10 的 FCU 功能与 Windows 8 进行了比较，Windows 对寄存器的使用进行了重新排序并保存了一条 AND 指令。这很可能是编译器优化，而不是源代码更改。因为左移的一半没有被屏蔽，所以你在 16-23 位得到了垃圾，但这些位应该被忽略。对于遵循 Windows ABI 的任何人来说，该函数仍然是正确的。

最好的解决方案是更新函数声明，使其使用 16 位整数类型。如果这不可能，您可以将数字转换为支持转换的语言中的 16 位类型。最后的选择是通过与0xffff 进行ANDing 自己截断值：

htonsNumber = BitAnd(htons(portNumber), 0xffff)

SHORT is listed as a valid return type 这样应该也能正常工作：

DECLARE SHORT htons IN "wsock32.dll" INTEGER

【讨论】：