On Tue, Mar 20, 2018 at 03:05:12PM +0100, Willy Tarreau wrote:
> On Tue, Mar 20, 2018 at 06:45:08PM +0500, ???? ??????? wrote:
> > "UB" stands for undefined behaviour. that's the reason why cppcheck is
> > unhappy.
> > how do that properly - that's the question :)
>
> The thing is that I'm not aware of any other way to safely detect integer
> overflows, it's always done like this. In fact this undefined behaviour
> on unsigned ints is defined per-architecture. I think you can safely turn
> this one off as we do use integer wrapping at other places on purpose, and
> we even build with -fwrapv to make it defined :-)
Well, I misinterpreted the doc for -fwrapv, for me it implied
-fno-strict-overflow but the wording made me doubt, to the point that I
wrote a small test program to test it. The doc says :
"When -fwrapv is used, there is no difference between
-fstrict-overflow and -fno-strict-overflow for integers."
But it appears I was wrong, the wording is specious enough (other parts
of the same man page are even dubious). I'm using -fwrapv, and setting
-fstrict-overflow or not differs, which contradicts the sentence above.
The key difference here is "for integers". In practice you *need* to
have both -fno-strict-overflow and -fwrapv to have a defined overflow
that also covers pointers. I've just checked what Linux does here and
it also sets -fno-strict-overflow to get rid of this purposeful crap.
So I'll add -fno-strict-overflow here to ensure that *all* overflows
(integer and pointers) act as expected and implemented when placed in the
underlying registers.
I have no idea how many programs have become vulnerable with this change
that silently happened around gcc 4.2 because I've been seeing this test
for overflows about everywhere people had at least some care for overflows,
which is sad :-/ The worst thing here is that -Wstrict-overflow never tells
you anything about this one while the compiler takes the freedom to play
with it in your back.
Bah. I'll go find a new job.
Thanks,
Willy
