3 ms·
As always with different designs from smart people, it’s about priorities. The profiles proposal focuses on a lack of annotations (I think there’s reasonable c
by steveklabnik 2y ago
As always with different designs from smart people, it’s about priorities.
The profiles proposal focuses on a lack of annotations (I think there’s reasonable criticism that this isn’t achieved by it though…), and believing they can get 80% of the benefit for 20% of the effort (at least conceptually, obviously not those exact numbers). They aren’t shooting for full memory safety.
The Safe C++ proposal asks “how do we achieve 100% memory safety by default?”. And then asks what is needed to achieve that goal.
- ameliaquining 2y agoWhat's with the "this model detects all possible errors" quote at the beginning of the post, then?
- steveklabnik 2y agoThat’s a claim about dangling pointers and ownership. Profiles do not solve aliasing or concurrency, as two examples of things that Safe C++ does that are important for memory safety.
- ameliaquining 2y agoConcurrency, sure, I can see thinking of that as a separate thing (as some people from Google have advocated for). But aliasing isn't a memory safety violation, it's a cause of memory safety violations (and other kinds of bugs besides). The first example from the linked post is straightforwardly a dangling pointer dereference, and I don't understand how the people behind safety profiles can claim that it's out of scope just because it involves aliasing. Did they say something like "this assumes your code follows these non-machine-checkable aliasing rules, if it doesn't then all bets are off"?
- steveklabnik 2y agoSure, I said “aliasing” to mean “these rules do not prevent memory unsafety due to misusing aliased pointers.” I hesitate to answer your question, but my impression is the answer is that they’re just not shooting for 100% safety, and so it’s acceptable to miss this kind of case.