diff options
author | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2015-12-31 10:47:22 +0000 |
---|---|---|
committer | abiesheuvel <abiesheuvel@Edk2> | 2015-12-31 10:47:22 +0000 |
commit | b331b99fae1298232cc4ab1e4bfedf79935fe2e6 (patch) | |
tree | d334e432c1cc8dcb67d9e9a9975d7d03775118e8 /AppPkg | |
parent | fcae1a993676997c8c21e95b7e69663683c326db (diff) | |
download | edk2-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