Here is the code that compiles with the Windows SDK:
UINT cFiles = DragQueryFileW(hDrop, 0xFFFFFFFF, NULL, 0);
where DragQueryFileW() has this signature:
UINT DragQueryFileW(HDROP, UINT, LPWSTR, UINT );
and UINT defined somewhere in the SDK headers as follows:
typedef unsigned int UINT;
for a platform where int is definitely 32-bit. As usual, types like UINT have a fixed width independent of the bit system, so if the same code needs to be recompiled on some other platform, where DragQueryFileW() redefined in some way, there will also be a corresponding typedef which will make the UINT card a suitable 32-bit unsigned type.
Now there is a static analysis tool that looks at the constant 0xFFFFFFFF and complains that it is an unsportsmanlike magic number, and -1 should be used instead . Although, of course, -1 is good and portable, I don’t see how there might be a problem with the constant 0xFFFFFFFF , because even when porting this type it will still be 32-bit, and the constant will be fine.
Uses 0xFFFFFFFF instead of -1 so that all bits are safe and portable in this scenario?
source share