[Bug c/107890] UB on integer overflow impacts code flow

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Keywords||diagnostic

--- Comment #5 from Eric Gallager  ---
What I wonder is, why doesn't -Wstrict-overflow=5 catch this? That's supposed
to be its strictest level, right?

$ /usr/local/bin/gcc -Wall -Wextra -pedantic -Wstrict-overflow=5 -O2 107890.c
107890.c: In function 'f':
107890.c:13:25: warning: comparison of integer expressions of different
signedness: 'int32_t' {aka 'int'} and 'long unsigned int' [-Wsign-compare]
   13 | if (i >= 0 && i < sizeof(tab)) {
  | ^
107890.c: In function 'main':
107890.c:21:18: warning: unused parameter 'ac' [-Wunused-parameter]
   21 | int main(int ac, char **av)
  |  ^~
$

[Bug c/107890] UB on integer overflow impacts code flow

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890

--- Comment #4 from Andrew Pinski  ---
There is always a trade off here.
We made the decision that signed integer overflow is undefined because we want
to do optimizations. Gcc does provide an option which makes them behave well
defined at runtime, -fwrapv . This is similar to strict aliasing with respect
to optimizations in the sense it is hard to decide if the optimizations is
being done will break what people assumptions are. This is part of the reason
why there is a specifications (standard) so people can write to it.
There are other undefined behavior that gcc has started to take advantage of
(e.g. in c++ if there is no return with a value in a function with that returns
non-void). The question is where do you draw the line with respect to undefined
behaviors, the answer is complex sometimes, especially if you are optimizing.

In this example the range of x is known to be positive so multiplying by
another positive # gives a positive result and then dividing by a positive
value still is positive. The check for negative result is optimized away.

[Bug c/107890] UB on integer overflow impacts code flow

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #3 from Martin Uecker  ---

Of course, instead of using the standard as an excuse, we could also try to
make the compiler less of a footgun. 

Even if this is standard conforming, it is still a severe usability issue with
safety implications and I do not think we should simply close such bugs.

[Bug c/107890] UB on integer overflow impacts code flow

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890

--- Comment #2 from Jonathan Wakely  ---
You should read https://blog.regehr.org/archives/213

[Bug c/107890] UB on integer overflow impacts code flow

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
>I was under the impression that this kind of undefined behavior essentially 
>meant that the value of that integer could become unreliable.

Your impression is incorrect. Once undefined behavior happens, anything can
happen. 

This is why things like -fsanitize=undefined is there now.