Hi,
On 03/06/13 00:16, Kinney, Michael D wrote:
> I think the BITxx, SIZExx, and BASExx macros should likely all use a
> 'u' suffix to force inform compilers that these values are to be
> interpreted as unsigned. The one with bits 32..63 set all have a
> 'ULL' suffix now.
It crossed my mind that the int-typed macros could be such on purpose.
(I'm late to realize this, because I personally would never do what
follows.)
Namely, as discussed before, ~(BIT5 | BIT3 | BIT1) is indeed negative,
hence when converted to an unsigned type, the high bits are *all* set,
independently of the target type size. Conversions to UINT64, UINT32,
UINT16, UINT8 all work as intended.
(This is the consequence of the conversion specifying the mathematical
result as
k * (UINTx_MAX + 1) + negative_value
such that "k" is an integer and that the result is in range for the
target type. See C99 6.3.1.3p2.)
IOW, the one culprit is BIT31 in this scheme, because its unsigned.
Now if we suffix BIT0..BIT30 with "u" too, then the following will stop
working as originally intended:
(UINT64) ~(BIT5 | BIT3 | BIT1)
because "sign-extension" will be replaced by "zero-extension".
Of course the following would continue to work (which is how I'd have
originally put all such complement masks):
~((UINT64) (BIT5 | BIT3 | BIT1))
Just a thought.
Laszlo
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
