[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined behavior sanitizing with Clang
From: |
Philipp Kutin |
Subject: |
Re: Undefined behavior sanitizing with Clang |
Date: |
Mon, 18 Nov 2013 23:27:58 +0100 |
I started to look at this a bit. My current plan is to split xisint()
into three functions, for simplicity of review:
xisint_sym: the symmetric variant [INT_MIN+1, INT_MAX].
xisint_full: the "normal" variant [INT_MIN, INT_MAX].
xisint: [INT_MIN+1, INT_MIN-1], kept in already correct (but maybe too
strict) code to not confuse anything.
The symmetric one will be used whenever there's the possibility of the
cast value negating, as -INT_MIN is undefined behavior, too.
Right now, I'm a bit confused seeing code like this:
if (xisint (btmp))
result(i) = std::pow (a, static_cast<int> (btmp));
else
result(i) = std::pow (a, btmp);
The assumption here seems to be that "std::pow(T, int)" will yield a
different result than "std::pow(T, double)" when given an
integer-valued second argument. Why?
--Philipp