4 ms·

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer ove

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C++ Guidelines). I don't see any reason why modern C++ wouldn't be just as spatially memory safe as Zig is, if we're allowed to subset the language in ways more trivial than "disable the unsafe keyword". The main thing that distinguishes Zig at that point would be that it's a simpler language. That's true. But I don't actually think that makes for safer programs, empirically speaking--otherwise, C programs would be safer than C++ programs, and they generally aren't.

azakai 4y ago
Yes, technically there might exist a subset of C++ as safe as idiomatic Zig. But in practice inertia and legacy code and lack of ergonomics etc. work against that subset of C++ becoming popular - does anyone constantly type .at()? Zig can do better, if it doesn't squander the opportunity. In other words, this isn't about theoretical subsets of a language. It's that there is an opportunity when designing a new language to use better defaults and have better idiomatic patterns. If Zig and Carbon do it properly, I think they can get to a place where they have practically no spatial memory errors in the real world. That is measurable, in principle, so we'll see how it plays out I suppose.
- burntsushi 4y ago
  I think it's worthwhile to point out that there are two threads of argument here. One is what it means to be spatially memory safe. Another is whether and how effective various mitigations are.
- pjmlp 4y ago
  Instead of typing .at() you do #define _ITERATOR_DEBUG_LEVEL 1, done now operator[]() does bounds checking as well.
user45 4y ago
Note that STL containers allow you to bounds check "[]" indexing even in release mode if you set the right preprocessor directives. The flag differs between compilers and stdlib implementations, though. For libstdc++ (default on linux), use _GLIBCXX_ASSERTIONS. For example, the following code aborts on release builds too: // g++ -O3 -D_GLIBCXX_ASSERTIONS=1 file.cpp #include <iostream> #include <vector> int main() { std::vector<int> vec{1, 2, 3, 4}; std::cout << vec[4]; } MSVC provides similar functionality using the _ITERATOR_DEBUG_LEVEL directive. The point is that there is no inherent limitation that one has to use the .at() method for bounds checking STL container access.
- azakai 4y ago
  Good to know, thanks!
pron 4y ago
> I don't see any reason why modern C++ wouldn't be just as spatially memory safe as Zig is Well, you'd need to avoid arrays and pointer arithmetic, some of the most basic language primitives, but being safer than C++ (even though it is) is not Zig's only or even main differentiation from C++. > But I don't actually think that makes for safer programs, empirically speaking--otherwise, C programs would be safer than C++ programs, and they generally aren't. Once again you're begging the question by trying to draw similarities between C and Zig and using extrapolations that you yourself know to be wrong. We both agree that the sweet spot for correctness is somewhere on the spectrum between C and Idris, but we really don't know more than that. No one is claiming that any language X that's simpler than another language Y will be more effective at producing correct programs, just as no one is claiming the same for any language X that can offer more sound guarantees than Y. In fact, we know that both of these statements are wrong. What we know is that simplicity and soundness are both sometimes better for correctness but neither is always better for correctness. I.e., we know that we cannot make the extrapolations that you're making.

azakai 4y ago

Yes, technically there might exist a subset of C++ as safe as idiomatic Zig. But in practice inertia and legacy code and lack of ergonomics etc. work against that subset of C++ becoming popular - does anyone constantly type .at()? Zig can do better, if it doesn't squander the opportunity. In other words, this isn't about theoretical subsets of a language. It's that there is an opportunity when designing a new language to use better defaults and have better idiomatic patterns. If Zig and Carbon do it properly, I think they can get to a place where they have practically no spatial memory errors in the real world. That is measurable, in principle, so we'll see how it plays out I suppose.

burntsushi 4y ago
I think it's worthwhile to point out that there are two threads of argument here. One is what it means to be spatially memory safe. Another is whether and how effective various mitigations are.
pjmlp 4y ago
Instead of typing .at() you do #define _ITERATOR_DEBUG_LEVEL 1, done now operator[]() does bounds checking as well.

user45 4y ago

Note that STL containers allow you to bounds check "[]" indexing even in release mode if you set the right preprocessor directives. The flag differs between compilers and stdlib implementations, though. For libstdc++ (default on linux), use _GLIBCXX_ASSERTIONS. For example, the following code aborts on release builds too: // g++ -O3 -D_GLIBCXX_ASSERTIONS=1 file.cpp #include <iostream> #include <vector> int main() { std::vector<int> vec{1, 2, 3, 4}; std::cout << vec[4]; } MSVC provides similar functionality using the _ITERATOR_DEBUG_LEVEL directive. The point is that there is no inherent limitation that one has to use the .at() method for bounds checking STL container access.

azakai 4y ago
Good to know, thanks!

pron 4y ago

> I don't see any reason why modern C++ wouldn't be just as spatially memory safe as Zig is Well, you'd need to avoid arrays and pointer arithmetic, some of the most basic language primitives, but being safer than C++ (even though it is) is not Zig's only or even main differentiation from C++. > But I don't actually think that makes for safer programs, empirically speaking--otherwise, C programs would be safer than C++ programs, and they generally aren't. Once again you're begging the question by trying to draw similarities between C and Zig and using extrapolations that you yourself know to be wrong. We both agree that the sweet spot for correctness is somewhere on the spectrum between C and Idris, but we really don't know more than that. No one is claiming that any language X that's simpler than another language Y will be more effective at producing correct programs, just as no one is claiming the same for any language X that can offer more sound guarantees than Y. In fact, we know that both of these statements are wrong. What we know is that simplicity and soundness are both sometimes better for correctness but neither is always better for correctness. I.e., we know that we cannot make the extrapolations that you're making.