summaryrefslogtreecommitdiff
path: root/AppPkg
diff options
context:
space:
mode:
authorArd Biesheuvel <ard.biesheuvel@linaro.org>2015-12-31 10:47:22 +0000
committerabiesheuvel <abiesheuvel@Edk2>2015-12-31 10:47:22 +0000
commitb331b99fae1298232cc4ab1e4bfedf79935fe2e6 (patch)
treed334e432c1cc8dcb67d9e9a9975d7d03775118e8 /AppPkg
parentfcae1a993676997c8c21e95b7e69663683c326db (diff)
downloadedk2-platforms-b331b99fae1298232cc4ab1e4bfedf79935fe2e6.tar.xz
MdePkg/BaseLib: do not rely on undefined behavior in arithmetic shift
The runtime test whether the compiler supports arithmetic shift of negative signed numbers currently relies on undefined behavior in C, which means that all bets are off regarding whether the condition that follows passes or fails, regardless of whether the compiler in fact supports arithmetic shift or not. Relevant quote from ISO C99 (6.5.7/4) The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 × 2^E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 × 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. For historic purposes, let's keep the test in place (although it is doubtful we actually need it) but rewrite it in a way that prevents compilers from this century from doing whacky things with it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19580 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'AppPkg')
0 files changed, 0 insertions, 0 deletions