使用 0xFFFFFFFF 是否是设置 32 位类型中所有位的可靠方法？
有一段使用 Windows SDK 编译的代码：
UINT cFiles = DragQueryFileW(hDrop, 0xFFFFFFFF, NULL, 0);
其中 DragQueryFileW() 具有此签名：
UINT DragQueryFileW(HDROP, UINT, LPWSTR, UINT );
并且 UINT 在 SDK 标头中的某处定义，如下所示：
typedef unsigned int UINT;
对于其中 int 的平台 肯定是 32 位的。像往常一样，像 UINT 这样的类型意味着具有独立于系统位数的固定宽度，因此如果必须在其他平台上重新编译相同的代码，其中 DragQueryFileW()以某种方式重新实现时，还会有一个相应的 typedef ，它将使 UINT 映射到合适的 32 位无符号类型。
现在有一个静态分析工具，它查看 0xFFFFFFFF 常量，并抱怨它是一个不可移植的幻数，并且应该使用 -1 代替。当然 -1 很好并且可移植，但我看不出使用 0xFFFFFFFF 常量在这里可能会出现问题，因为即使移植时类型仍然是 32 位常数就可以了。
在这种情况下，是否使用 0xFFFFFFFF 而不是 -1 来设置所有位的安全性和可移植性？
There's this code that compiles with Windows SDK:
UINT cFiles = DragQueryFileW(hDrop, 0xFFFFFFFF, NULL, 0);
where DragQueryFileW() has this signature:
UINT DragQueryFileW(HDROP, UINT, LPWSTR, UINT );
and UINT is defined somewhere in SDK headers like this:
typedef unsigned int UINT;
for the platform where int is surely 32-bits. As usual, types like UINT are meant to have fixed width independent on the system bitness, so if the same code has to be recompiled on some other platform, where DragQueryFileW() is reimplemented somehow there will also be a corresponding typedef that will make UINT map onto a suitable 32-bit unsigned type.
Now there's a static analysis tool that looks at 0xFFFFFFFF constant and complains that it is an unportable magic number and one should use -1 instead. While of course -1 is good and portable I can't see how using the 0xFFFFFFFF constant could be a problem here since even when porting the type will still be 32-bit and the constant will be fine.
Is using 0xFFFFFFFF instead of -1 to set all bits safe and portable in this scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
填充所有位（无论类型大小）的可移植方式实际上是：
如：
或者使用 C99 类型名称更可移植：
C 标准保证分配 -1 设置所有位。
现在，如果您可以保证您的变量是无符号 32 位，那么使用
0xFFFFFFFF当然也可以。但我仍然会选择-1变体。The portable way to fill all bits (regardless of type size) is really:
as in:
or more portable using C99 type names:
The C standard guarantees that assigning -1 sets all bits.
Now, if you can guarantee that your variable is unsigned 32 bits then using
0xFFFFFFFFis alright as well, of course. But I'd still go for the-1variant.你可以使用：
you could use:
我发现 0xFFFFFFFF 的一个潜在问题是您很容易会错过一个 F 并以完整的虚拟值进行初始化。
我认为最好定义一个常量：
并在任何地方使用它。
One potential problem I see with 0xFFFFFFFF is that you can easily miss one F and initialize in a complete dummy value.
I believe that it is better to define a constant:
and use that everywhere.
0xffffffff 无疑是将所有位设置为 32 位中的一位的可靠方法。但我不会依赖 UINT 总是 32 位。
为了让它不那么“神奇”，你也可以写它： (1 << 32) - 1
0xffffffff is for sure a reliable way to set all bits to one in 32 bits. but I wouldn't depend on a UINT always being 32 bits.
to make it less "magic" you could also write it: (1 << 32) - 1