Message: 2
Date: Thu, 14 Nov 2013 12:28:36 +0100
From: Philipp Kutin <address@hidden>
To: address@hidden
Subject: Re: Undefined behavior sanitizing with Clang
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
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
11/14/13