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

[miroslav.fontan]

I do not think this is a false positive. In my view it is the loss of data
or poor application design when it is necessary to convert data and/or lose
accuracy.

A very good idea is to distinguish implicit and explicit conversion,
explicit conversion is clearly expressed intent of the programmer that he
wants to change the integer type. Therefore, I see hidden implicit
conversion as more dangerous

Data truncation by the implicit conversion behavior can be expected if you
know and follow exactly the conversion rules. Unfortunately, in most cases
it is commonly programmers ignorance/error and this leads to unwanted
side-effect.

If I had voting rights, I voted for this feature ;-)

MF

> -----Original Message-----
> From: Will Dietz [mailto:w at wdtz.org]
> Sent: Wednesday, January 22, 2014 11:10 PM
> To: Richard Smith
> Cc: Yury Gribov; John Regehr; miroslav.fontan; David Blaikie; cfe-dev
> Developers
> Subject: Re: [cfe-dev] A need for an "-fsanitize=integer-assign-
> overflow"
> 
> 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