Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 2, 2023 23:59 UTC (Thu) by anton (subscriber, #25547)
In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by vadim
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

You can't break something that's currently declared UB.

If the UB lovers repeat their position often enough (and there is lots of that repetition in this discussion), you may find yourself adopting it even if it is incompatible with your other positions. Beware!

As for -fwrapv, making it the default is very unlikely to break existing, tested code for gcc, because gcc usually compiles code as if -fwrapv was given, and only deviates from that if it can detect a special case. No experienced programmer will bet on that special case being treated the same way after some program maintenance or the like.

A more likely reason for gcc not making -fwrapv the default is that it would require sign-extending int in array accesses on some 64-bit architectures in some code. In SPECint 2006, one of the benchmarks was slowed down by 7.2% by this sign extension if -fwrapv was enabled, resulting in <1% lower result for the whole benchmark suite (as reported by Wang et al.).

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 3, 2023 11:36 UTC (Fri) by farnz (subscriber, #17727) [Link]

And this is where the culture thing shows up; turning on -fwrapv is clearly a win for safety, since it means that the behaviour of signed integer overflow matches what most developers think it "should" be. But because there's a benchmark on which turning it on is a significant regression in performance, the default is "off".

If there was a different culture around C and C++, then -fwrapv would be the default, and there would be a way to opt-out of it if you know that you don't depend on the behaviour of signed integer wrapping, and want the performance back.