“＆0xFFFFFFFF”在这个HIDWORD宏中做了什么

Question

I needed the HIDWORD macro for a program I'm making and found this one here: http://gnuwin32.sourceforge.net/compile.html

What I'm confused about is why there is a &0xFFFFFFFF at the end of it?

#define HIDWORD(l) ((DWORD)(((DWORDLONG)(l)>>32)&0xFFFFFFFF))

How does that modify the output of this macro in any way?

Answer 1

I don't think it has any real effect - the (DWORD) cast that the final operation of the expression will force the result to 32 bits anyway.

The (DWORDLONG) cast forces the shift operation to act on an unsigned value, so no 'sign bits' will be shifted into the intermediate result. However, since the operand could be 64-bits, there might still be non-zero bits at higher locations than bit 31. The & 0xFFFFFFFF operation will zero out those bits, but so would the (DWORD) cast.

But it doesn't hurt, either. One could argue that it makes the intent of the macro clearer (except to you, maybe - just kidding!).

Answer 2

It's dealing with possible sign extension by explicitly masking out the high-order bits. Whether your compiler actually does sign extension for a right shift of a negative is implementation-defined.

EDIT: Sign extension refers to setting the high-order bits to keep the sign when a number is shifted.

For example:

11111110

is -2, if we assume it's a 8-bit two's complement number. If we do a simple logical shift right, we get:

01111111

However, that changes the sign of the number. Many compilers will do a arithmetic shift, to give:

11111111

Note that we fill in the most significant bit (it would be more than one for a more complex example) with 1's.

Answer 3

Assuming those are unsigned types, and assuming DWORD is 32 bits and DWORDLONG is 64 bits, then technically it doesn't do anything.

Perhaps it's just code left over from copy-and-paste of similar macro for signed types?

Or perhaps one the assumptions I noted doesn't hold.

Cheers & hth.,