3 ms·

But he’s not engaging with the issue of memory safety here. > Since at least 2014, Bjarne Stroustrup has advocated addressing safety in C++ via a “subset of a

But he’s not engaging with the issue of memory safety here. > Since at least 2014, Bjarne Stroustrup has advocated addressing safety in C++ via a “subset of a superset”: > As of C++20, I believe we have achieved the “superset,” notably by standardizing span, string_view, concepts, and bounds-aware ranges. We may still want a handful more features, such as a null-terminated zstring_view, but the major additions already exist. Sounds like Herb too believes that C++ is making good progress and that it’s a library issue. This is problematic when the default `[]` API that everyone uses has no bounds check. So then you change the compiler to have an option to always emit a bounds check. But then you don’t have an escape hatch when performance is important. Herb is always defending against switching away from C++ and that C++ will solve the problems in a back compat way. They’ve been disrupted and they’ve taken a classical defensive approach instead of actually trying to compete which would require a massive restructuring of how C++ is managed as a language (e.g. coalescing the entire ecosystem onto a single front-end so that new language features only need to be implemented once). They need to be more radical in their strategy but that doesn’t gel with design by committee.

fweimer 3y ago
Fedora & downstream build with -D_GLIBCXX_ASSERTIONS, which enables bounds checking for many of those operator[] calls (including std::vector). For tight loops, GCC can often eliminate the bounds checks, at least if you use size_t (or size_type) for the loop iteration variable, not unsigned.
nindalf 3y ago
He’s suggesting adding bounds checks automatically by the compiler, which is vastly more than Stroustrup was recommending. He reckoned merely running sanitizers was sufficient. He wasn’t even taking the problem seriously, as if it’s a given that the world will continue using C++ no matter what. The fact that Sutter is willing to sacrifice performance for safety means at least he has woken up to the reality that the future may hold less C++ code than the past.
- vlovich123 3y ago
  But without a way to recoup the performance when you need it, then C++ potentially becomes as slow as things like Go or Java with extra footguns and slower developer speed. That's why Rust has `unsafe` and `unchecked` API methods that you can use in unsafe to bypass bounds checks. And it's an extremely consistent API surface to deal with (not to mention a much better thread safety story which Herb hand waves away as "not important because other languages also have thread safety issues" even though he admits no one is as bad as C++ here).
rerdavies 3y ago
> This is problematic when the default `[]` API that everyone uses has no bounds check. The default [] API can be replaced with C++ classes that do bounds checks. C++ 20 provides the std::array class to do precisely that, and std::span to implement fat pointers. All that's missing to implement the subset-of-a-superset mode is a compiler option to disable native arrays in C++ code (but not in extern "C" code).
- vlovich123 3y ago
  > The default [] API can be replaced with C++ classes that do bounds checks Which means you subtly break the performance guarantees of code which makes migration to a new version more annoying. > C++ 20 provides the std::array class to do precisely that What? https://en.cppreference.com/w/cpp/container/array/operator_at https://en.cppreference.com/w/cpp/container/array/operator_a... > Returns a reference to the element at specified location pos. No bounds checking is performed > option to disable native arrays in C++ code Yeah, no that's not the only place where bounds checking shows up. Lots of places use pointers as iterators because the language lets you. So even if you shut off those avenues, code that uses pointers as iterators would remain exploitable. Of course it's a step improvement, but there's just no way to close the barn door for C++ unless you sacrifice performance to such a degree that the obvious question becomes "why restricted C/C++" which still has a bunch of footguns, is slow, and which has a really inconsistent API and language surface?

fweimer 3y ago

Fedora & downstream build with -D_GLIBCXX_ASSERTIONS, which enables bounds checking for many of those operator[] calls (including std::vector). For tight loops, GCC can often eliminate the bounds checks, at least if you use size_t (or size_type) for the loop iteration variable, not unsigned.

nindalf 3y ago

He’s suggesting adding bounds checks automatically by the compiler, which is vastly more than Stroustrup was recommending. He reckoned merely running sanitizers was sufficient. He wasn’t even taking the problem seriously, as if it’s a given that the world will continue using C++ no matter what. The fact that Sutter is willing to sacrifice performance for safety means at least he has woken up to the reality that the future may hold less C++ code than the past.

vlovich123 3y ago
But without a way to recoup the performance when you need it, then C++ potentially becomes as slow as things like Go or Java with extra footguns and slower developer speed. That's why Rust has `unsafe` and `unchecked` API methods that you can use in unsafe to bypass bounds checks. And it's an extremely consistent API surface to deal with (not to mention a much better thread safety story which Herb hand waves away as "not important because other languages also have thread safety issues" even though he admits no one is as bad as C++ here).

rerdavies 3y ago

> This is problematic when the default `[]` API that everyone uses has no bounds check. The default [] API can be replaced with C++ classes that do bounds checks. C++ 20 provides the std::array class to do precisely that, and std::span to implement fat pointers. All that's missing to implement the subset-of-a-superset mode is a compiler option to disable native arrays in C++ code (but not in extern "C" code).

vlovich123 3y ago
> The default [] API can be replaced with C++ classes that do bounds checks Which means you subtly break the performance guarantees of code which makes migration to a new version more annoying. > C++ 20 provides the std::array class to do precisely that What? https://en.cppreference.com/w/cpp/container/array/operator_at https://en.cppreference.com/w/cpp/container/array/operator_a... > Returns a reference to the element at specified location pos. No bounds checking is performed > option to disable native arrays in C++ code Yeah, no that's not the only place where bounds checking shows up. Lots of places use pointers as iterators because the language lets you. So even if you shut off those avenues, code that uses pointers as iterators would remain exploitable. Of course it's a step improvement, but there's just no way to close the barn door for C++ unless you sacrifice performance to such a degree that the obvious question becomes "why restricted C/C++" which still has a bunch of footguns, is slow, and which has a really inconsistent API and language surface?