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

Posted Nov 7, 2023 17:35 UTC (Tue) by adobriyan (subscriber, #30858)
In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by farnz
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

> we have noises about -fwrapv being too expensive

-fwrapv gains/losses are trivial to measure in theory:
Gentoo allows full distro recompile with seemingly arbitrary compiler flags.
I was using "-march=native" more or less since the moment it was introduced.

> If you can't get agreement on something that trivial, where the performance cost (while real, as shown by SPECint 2006) can be deal with by relatively simple refactoring to make things that should be unsigned into actual unsigned types instead of using int for everything, what hope is there for fixing other forms of UB?

Making types unsigned is not simple, the opportunities for introducing new bugs are limitless.

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

Posted Nov 7, 2023 17:43 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

-fwrapv slows some sub-tests in SPECint 2006 by around 5% to 10% as compared to -fno-wrapv. This is unacceptably large, even though in the cases where it regresses, someone's already done the analysis to confirm that it regresses because it used int for array indexing instead of size_t.

And note that, by the nature of -fwrapv, every case where it regresses performance is one where the source code is already buggy, because it depends on UB being interpreted in a way that suits the programmer's intent, and not in a different (but still legal) way. It cannot change anything where the program's behaviour was fully defined without -fwrapv, since all -fwrapv actually does is say "these cases, which used to be Undefined Behaviour, now have the following defined semantics". But that was already a legal way to interpret the code before the flag changed the semantics of the language, since UB is defined as "if you execute something that contains UB, then the entire meaning of the program is undefined and the compiler can attribute any meaning it likes to the source code".

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

Posted Nov 7, 2023 18:34 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses)

> This is unacceptably large

… if you value "no performance regression even on UB-buggy code" higher than "sane(r) semantics and less UB".

As long as people who think along these lines are in charge of the C/C++ standards, Stroustrup’s plan (or indeed any plan to transform the language(s) into something safe(r)) has no chance whatsoever to get adopted.

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

Posted Nov 9, 2023 14:43 UTC (Thu) by pizza (subscriber, #46) [Link]

> As long as people who think along these lines are in charge of the C/C++ standards,

That's a little disingenuous; it's not that they're "in charge of C/C++" it's that there's a large contingent of *users* of C/C++ that ARE VERY VERY VOCAL about performance regressions in _existing_ code.

There's a *lot* of existing C/C++ code out in the wild, representing a *lot* of users. And many of those users are pulling the C/C++ standards in mutally-incompatible ways.

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

Posted Nov 16, 2023 20:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

The plan (AFAICT) seems to be along the lines of defining rules that code must obey in order to satisfy profiles. Once the rules are known, language and library constructs can be analyzed to see if they adhere to those rules and called out by the compiler from there. While it will take time for code to be under a set of profiles that gets Rust-like safety, I think it is probably the most reasonable plan given the various constraints involved. But with this, one can start putting code behind "we checked for property X and want the compiler to enforce it from here on out" until you can start to say it project-wide and then start flipping the switch to say "we know we cannot adhere to property X for this function" getting something like Rust's `unsafe` "callout" that something special is going on here.

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

Posted Nov 9, 2023 23:15 UTC (Thu) by foom (subscriber, #14868) [Link] (5 responses)

> And note that, by the nature of -fwrapv, every case where it regresses performance is one where the source code is already buggy

Nope.

The flag only affects the _results_ if the program previously exhibited UB, but, it removes flexibility from the optimizer by requiring the result be wrapped. This may require additional conditions or less efficient code. If the more-optimal version didn't produce the correct result when the value wrapped, it cannot be used any more.

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

Posted Nov 10, 2023 13:55 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

Which is why my take is that - ON A 2S COMPLEMENT PROCESSOR - -fwrapv should be defined as the default. So by default, you get the expected behaviour.

Then they can compile SPECInt with a flag that switches off fwrapv to give the old behaviour and say "you want speed? Here you are! But it's safe by default".

So UB has now become hardware- or implementation-defined behaviour but the old behaviour is still available if you want it.

Cheers,
Wol

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

Posted Nov 10, 2023 14:00 UTC (Fri) by farnz (subscriber, #17727) [Link]

Now go and convince the Clang, GCC, Fedora or Debian maintainers that this should be the default state. That's the hard part - getting anyone whose decisions will influence the C standards body to declare that they want less UB, even at the expense of a few % of speed on some benchmarks.

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

Posted Nov 13, 2023 13:13 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

Is there anything that's been produced in the last 10 years that is /not/ twos-complement? (If "nothing" - in the last 20?)

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

Posted Nov 13, 2023 17:14 UTC (Mon) by kreijack (guest, #43513) [Link]

> Is there anything that's been produced in the last 10 years that is /not/ twos-complement? (If "nothing" - in the last 20?)

My understanding is that the ISO c++20 standard already mandates the two's complement:

If you look at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm, you can find more information; even an analysis about which processor is/was not "two's complement".

And also it seems that C23 also is following the same path.

Anyway I think that the right question is "which architecture" supported by GCC (or CLANG...) is/isn't two's complement.

https://en.wikipedia.org/wiki/C23_(C_standard_revision)#cite_note-N2412-62
https://en.wikipedia.org/wiki/C%2B%2B20#cite_note-32
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/...

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

Posted Nov 14, 2023 14:30 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

For "basic" operations, probably very few. What about vectorized operations? Are they consistently twos-complement? How about GPU and other specialized hardware?