Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Posted Nov 1, 2023 19:07 UTC (Wed) by mb (subscriber, #50428)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)
These defaults basically never change in C compilers. It could break somebody's code.
The world already has agreed that signed overflow UB is a bad idea these days. That's why this option exists and is in broad use.
But I also don't see the problem with putting these flags into your project's CFLAGS. That's easy enough.
Posted Nov 1, 2023 19:35 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Generally speaking... you're correct, but in GCC 5, the default changed from gnu89 to gnu11, and to gnu17 in GCC 11. This broke a lot of (old, barely-if-at-all-maintained) codebases that had neglected to specify which standard they utilized. This was easily rectified (eg by adding -std=gnu89 to your CFLAGS)
(For C this wasn't _that_ big of a deal, but C++11 also came with a significant ABI break, which significantly affected the common practice of using 3rd-party-supplied binary libraries)
On the other hand, the set of optimizations/checks enabled at different standard levels (eg -O1/2/s/etc) usually changes with each compiler release, and that can lead to "breakages" in existing code. (One can quibble about how how this doesn't actually count as "defaults", but it's still something folks have to deal with in the real world)
Posted Nov 1, 2023 20:04 UTC (Wed)
by vadim (subscriber, #35271)
[Link] (3 responses)
You can't break something that's currently declared UB. UB is UB, there are no rules.
Posted Nov 1, 2023 20:28 UTC (Wed)
by mb (subscriber, #50428)
[Link]
That's exactly why C optimizer developers think it's Ok to throw away security checks.
In reality, though, C/C++ programs are full of UB. The compiler is just not smart enough to break it, yet.
Posted Nov 2, 2023 23:59 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
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
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.
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
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!
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)