Why Safety Profiles Failed • Hacker News Board

Re: Why Safety Profiles Failed

#51

Post by steveklabnik » Fri, Oct 25, 2024, 2:01 AM UTC

ameliaquining wrote: post #40

These considerations all seem so self-evident that I can't imagine the architects of Safety Profiles weren't aware of them; they are basically just the statement of the problem. And yet these smart people presumably thought they had some kind of solution to them. Why did they think that? What did this solution look like? I would be very interested to read more context on this.

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.

Re: Why Safety Profiles Failed

#52

Post by prophesi » Fri, Oct 25, 2024, 2:03 AM UTC

For those without a dark mode extension:

body {

  background-color: #1f1f1f;

  color: #efefef;

}

.sourceCode {

  background-color: #3f3f3f;

}

Re: Why Safety Profiles Failed

#53

Post by [deleted] » Fri, Oct 25, 2024, 2:09 AM UTC

ameliaquining wrote: post #40

These considerations all seem so self-evident that I can't imagine the architects of Safety Profiles weren't aware of them; they are basically just the statement of the problem. And yet these smart people presumably thought they had some kind of solution to them. Why did they think that? What did this solution look like? I would be very interested to read more context on this.

[deleted]

Re: Why Safety Profiles Failed

#54

Post by safercplusplus » Fri, Oct 25, 2024, 2:17 AM UTC

wyager wrote: post #32

alilleybrinker wrote: post #18

Earlier quoted context omitted.

Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1]. Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the…

> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.

In theory it could be auto-converted to a safe subset of C++ [1]. In theory it could be done at build-time, like the sanitizers.

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Re: Why Safety Profiles Failed

#55

Post by safercplusplus » Fri, Oct 25, 2024, 2:27 AM UTC

pavon wrote: post #38

wyager wrote: post #32

Earlier quoted context omitted.

> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.

Why not? C++ has evolved over the years, and every C++ project I have worked on, we've adopted new features that make the language safer or clearer as they are supported by the compilers we target. It doesn't get applied to the entire codebase overnight, but all new code uses these features, refactors adopt them as much as possible, and classes of bugs found by static code scanning cause them to be adopted sprinkled…

You might consider experimenting with the scpptool-enforced safe subset of C++ (my project). It should be even less disruptive.

[1] https://github.com/duneroadrunner/scpptool

Re: Why Safety Profiles Failed

#56

Post by nickitolas » Fri, Oct 25, 2024, 2:53 AM UTC

whimsicalism wrote: post #48

ameliaquining wrote: post #42

Earlier quoted context omitted.

I think maybe it's because lifetime annotations can get arbitrarily complicated. If you look at enough Rust code you'll definitely see some function signatures that make your head hurt, even if they're vastly outnumbered by simple ones. A guarantee that the comprehension complexity of that part of your code will always be below some low ceiling is tempting.

Rust has nothing on template meta programming and the type signatures you get there, though

Not to mention the error messages when you get something slightly wrong

Re: Why Safety Profiles Failed

#57

Post by saagarjha » Fri, Oct 25, 2024, 2:54 AM UTC

bfrog wrote: post #44

favorited wrote: post #30

I know Sean said on Twitter that he probably won't submit this to WG21, but I wish he would... It is a fantastic rebuttal of certain individual's continued hand-waving about how C++ is safe enough as-is.

This seems to be a common theme with many c++ developers honestly.

Some of them are unfortunately on language committees.

Re: Why Safety Profiles Failed

#58

Post by crest » Fri, Oct 25, 2024, 2:57 AM UTC

whimsicalism wrote: post #48

ameliaquining wrote: post #42

Earlier quoted context omitted.

I think maybe it's because lifetime annotations can get arbitrarily complicated. If you look at enough Rust code you'll definitely see some function signatures that make your head hurt, even if they're vastly outnumbered by simple ones. A guarantee that the comprehension complexity of that part of your code will always be below some low ceiling is tempting.

Rust has nothing on template meta programming and the type signatures you get there, though

Give the proc macro fans a little more time...

Re: Why Safety Profiles Failed

#59

Post by tsimionescu » Fri, Oct 25, 2024, 3:36 AM UTC

o11c wrote: post #7

"No mutable aliases" is a mistake; it prevents many useful programs. Now that virtual address space is cheap, it's possible to recompile C (or presumably C++) with a fully-safe runtime (requiring annotation only around nasty things like `union sigval`), but this is an ABI break and has nontrivial overhead (note that AddressSanitizers has ~2x overhead and only catches some optimistic cases) unless you mandate addition…

How would this fix memory safety issues like std::sort(vec1.begin(), vec2.end()) (where vec1 and vec2 are different vectors, of course)? Or strlen(malloc(100))?

Re: Why Safety Profiles Failed

#60

Post by nicoburns » Fri, Oct 25, 2024, 3:38 AM UTC

steveklabnik wrote: post #5

wyager wrote: post #4

Earlier quoted context omitted.

> Safe C++ is a really important project What makes you say this? It seems to me like we already have a lower-overhead approach to reach the same goal (a low-level language with substantially improved semantic specificity, memory safety, etc.); namely, we have Rust, which has already improved substantially over the safety properties of C++, and offers a better-designed platform for further safety research.

I am pro any movement towards memory safety. Sure, I won't stop writing Rust and start moving towards C++ for this. But not everyone is interested in introducing a second toolchain, for example. Also, as this paper mentions, Safe C++ can improve C++ Rust interop, because Safe C++ can express some semantics Rust can understand. Right now, interop works but isn't very nice. Basically, I want a variety of approaches, no…

> But not everyone is interested in introducing a second toolchain, for example.

Not that this invalidates your broader point about Safe C++, but this particular issue could also be solved by Rust shipping clang / a frontend that can also compile C and C++.