[Top][All Lists]

[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));
        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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]