[cfe-dev] A need for an "-fsanitize=integer-assign-overflow"

[Will Dietz]

In my experience, conversion checks[1] cause too many false positives
to be generally useful and
this is why these checks aren't presently done by Clang (in
-fsanitize=integer or otherwise).

One idea I explored to improve the situation is to distinguish
explicit from implicit conversion errors,
which might be good enough for general use.  That said, I'm unsure if
this really improves
the signal-to-noise ratio or simply lowers the volume of errors
reported, I'd have to spend
some time going back through my evaluation results.  That's not to say either
or both of these checks aren't potentially very useful to you in your
situation :).

I have a preliminary implementation of conversion check support
available on github
(clang[2], corresponding compiler-rt[3]) that may be of interest.

I've let these forks fall behind trunk quite a bit, but if you or
others think this would be
a useful set of checks I'd be willing to polish them and port to mainline
(potentially for inclusion).  Let me know, I've actually already done
most of this work privately so really am just looking for a compelling argument
to wrap it up :).

In short:

* I've implemented the sort of checks you describe
* My own research suggests they're too noisy for general use
* If you think you'd find them useful regardless, we should chat :)

~Will


[1] Here I mean any conversion where the result interpreted by the
destination type is not the same mathematical integer as the source
interepeted by the source type.  This can happen either due to
truncation or sign errors.  Note that truncation of bits might not be
an error,  consider -1 cast from int32_t to int8_t.

[2] https://github.com/dtzWill/ioc-clang
[3] https://github.com/dtzWill/ioc-compiler-rt

On Tue, Jan 21, 2014 at 3:21 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, Jan 21, 2014 at 1:15 AM, Yury Gribov <y.gribov at samsung.com> wrote:
>>
>> Are we talking about signed or unsigned overflows? Both may be useful but
>> second isn't UB.
>
>
> The subject is not overflow, it's truncating conversion. The semantics here
> are well-defined -- for a conversion to unsigned, they're defined in the
> language standard, and for a conversion to signed, they're
> implementation-defined. In the latter case, essentially all modern
> implementations define the conversion as a 2s complement truncation.
>
> So... neither of these belong in -fsanitize=undefined. They might make sense
> in -fsanitize=integer, though.
>
>>
>> > The question is whether it is worth implementing.
>>
>> There are some CWEs for it:
>> * CWE-197: Numeric Truncation Error
>> (http://cwe.mitre.org/data/definitions/197.html)
>> * CWE-192: Integer Coercion Error
>> (http://cwe.mitre.org/data/definitions/192.html)
>>
>> -Y
>
>