Re: Undefined behavior sanitizing with Clang

[Philipp Kutin]

Hi,

just build a Clang-SVN -fsanitize=address,undefined build of Octave HG
default again and ran its test suite. Trimmed results are attached.
The summary is that besides a couple of div-by-zero and the known
1e200/1e300-to-float conversion issues, there's only a single other
one, like this:

/home/pk/dl/octave-default/build/libinterp/../../libinterp/corefcn/sparse-xpow.cc:375:
runtime error: value 1.79769e+308 is outside the range of
representable values of type 'int'

This is caused by these kinds of tests in sparse.tst:

%!test bf=realmin;
%% Make sure newly introduced zeros get eaten
%!assert (nnz (sparse ([bf,bf,1]).^realmax), 1)

The C++ code in question,

      if (static_cast<int> (b) != b && a.any_element_is_negative ())

does a cast-to-int on a double that's not necessarily known to be in
the safe range for this conversion, the half-open interval (INT_MIN-1,
INT_MAX+1).

Looking at the top of sparse-xpow.cc, there already seems to exist a
function tailored to that range check, xisint(). However, I'm
wondering why it does the slightly too-strict check INT_MIN < x && x <
INT_MAX instead of the more liberal (and presumably still safe for the
uses that follow) INT_MIN <= x && x <= INT_MAX. (Well, or for
symmetry, INT_MIN < x && x <= INT_MAX.)

So, I'm definitely pretty happy to see such a clean output from the
Clang sanitizers. But then again I'm not sure whether the results now
and a couple of months ago are comparable. Clang seems to optimize
away some expresssions even at -O0 these days (experieced because it
seems harder to get a build useful for debugging), so hopefully it
takes care to insert the checks even then.

Greetings,
Philipp

MAKECHECK_CLANG_CHECK_3.log
Description: Text Data