Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

61–70 of 226 posts

Re: Safe C++ proposal is not being continued

#61

Post by pizlonator »

tialaramex wrote: post #57
pizlonator wrote: post #36

Earlier quoted context omitted.

> The profiles technology isn't very good. Can you be very specific about why? Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protectio…

Yes I can be specific. Firstly, you need composition. Rust's safety composes. The safe Rust library for farm animals from Geoff, the safe Rust library for cooking recipes by Alice and the safe Rust library for web server by Bert together with my safe program code adds up to my safe Rust farm foods web site. By having N profiles, where N is intended to be at least five and might grow arbitrarily and be user extensible…

I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety. So I don't buy your first and second points.

> Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck.

That's a bold statement. It might be true for some very loose definition of "borrow checker". See the super simple static analysis that WebKit uses (that presentation is now linked in at least two places on this HN discussion, so I won't link it again).

> Your idea to do the reference counting everywhere is not something WG21 has looked at, I think the perf cost is sufficiently bad that they won't even glance at it. They're also not going to ship a GC.

The point isn't to have ref counting on every pointer at the language level, but rather: if your prevent folks from calling `delete` directly (as one of the profiles does) then you're effectively forcing folks to use smart pointers.

Reference counting that happens by smart pointers is something that they would ship. We know this because it's already happened.

I imagine this would really mean that some references are ref counted (if you use shared_ptr or similar) while other references use some other policy.

> Finally though, C++ is a concurrent language. It has a whole memory model which doesn't even make sense if you aren't thinking about concurrency. But to deliver concurrent memory safety without Fil-C's overheads you would want... well, Rust's Send and Sync traits

Yeah, this might be an area where they leave a hole. Like, you might have reference counting that is only partially thread safe:

- The refcount of any object is atomic.

- The smart pointer itself is racy. So, racing on pointers can pop the protections.

If they got that far, then that wouldn't be so bad. The marginal safety advantage of Rust would be very slim at that point.

Re: Safe C++ proposal is not being continued

#62

Post by pizlonator »

steveklabnik wrote: post #59
pizlonator wrote: post #54

Earlier quoted context omitted.

> This is not the goal of profiles. It’s to be “good enough.” Guaranteed safety isn’t in the cards. - Rust isn’t totally guaranteed safe since folks can and do use unsafe code. - Exact same situation in Swift - Go has escape hatches like it you race, but not only. So most “safe” things are really “safe enough” for some definition of “enough”.

You’re misunderstanding what I’m saying. Safe Rust guarantees memory safety. Profiles do not. This is regardless of the ability of the unchecked versions, on both sides, to introduce issues. Profiles do not, even for code that is 100% using profiles, guarantee safety.

The kind of "safe Rust" where you never use `unsafe` and never call into a C library is theoretical. None of the major ports of software to Rust achieve that.

So, no matter what safe language we talk about, "safety" always has its caveats.

Can you be specific about what missing safety feature of profiles leads you to be so negative about them?

Re: Safe C++ proposal is not being continued

#63

Post by gmueckl »

coffeeaddict1 wrote: post #45
pizlonator wrote: post #36

Earlier quoted context omitted.

> The profiles technology isn't very good. Can you be very specific about why? Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protectio…

> And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere) That's going to be a non-starter for 99% of serious C++ projects there. The performance hit is going to be way too large. For bounds checking, sure I think the performance penalty is so small that it can be done.

You have to realize that the number of locations in code where reference counter adjustment is actually meaningful is rather small and there are simple rules to keep the excess thrash from reference counting pointer wrappers to a minimum. The main one, as mentioned in the talk the sibling comment called out, is that it is OK to pass a raw pointer or reference to a function while holding on to a reference count for as long as that other function runs (and doesn't leak the pointer through a side effect). This rule catches a lot of pointless counter arithmetic through excessive pointer wrapper copying.

Re: Safe C++ proposal is not being continued

#64

Post by steveklabnik »

pizlonator wrote: post #62
steveklabnik wrote: post #59

Earlier quoted context omitted.

You’re misunderstanding what I’m saying. Safe Rust guarantees memory safety. Profiles do not. This is regardless of the ability of the unchecked versions, on both sides, to introduce issues. Profiles do not, even for code that is 100% using profiles, guarantee safety.

The kind of "safe Rust" where you never use `unsafe` and never call into a C library is theoretical. None of the major ports of software to Rust achieve that. So, no matter what safe language we talk about, "safety" always has its caveats. Can you be specific about what missing safety feature of profiles leads you to be so negative about them?

No, I am saying that safe rust says “if unsafe is correct, safe rust means memory safety.” Profiles does not even reach that bar, it says “code under profiles is safer.”

It’s not about specifics, it’s about the stated goals of profiles. They do not claim to prove memory safety even with all of them turned on.

Re: Safe C++ proposal is not being continued

#65

Post by cass0wary »

Animats wrote: post #39
tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they hav…

TRACTOR is currently proceeding. The program is structured in phases. Each phase will present the participants with increasingly difficult challenges to translate. At the end of each phase the participants will be tested and the results of these tests will be publicly announced. The first phase of TRACTOR began in June and will run for six months.

Re: Safe C++ proposal is not being continued

#66

Post by ImTotallyVegan »

winrid wrote: post #47
flykespice wrote: post #43

C++ will never be safe as long as its C root persists, it doesn't matters how much freatures you add on top of C++ to make writing safe programs more convenient. You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.

C+++ :)

C+-

Re: Safe C++ proposal is not being continued

#67

Post by zozbot234 »

Animats wrote: post #39
tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they hav…

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity.

There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borrow checker, but that saves you countless days of debugging highly non-trivial defects, especially in a larger codebase.

> Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this.

FWIW, "classes with inheritance" in Rust can be very elegantly modeled with generic typestate. (Traits are used as part of this pattern, but are not the full story.) It might look clunky at first glance, but it accurately reflects the underlying semantics.

Re: Safe C++ proposal is not being continued

#68

Post by tialaramex »

pizlonator wrote: post #34
favorited wrote: post #13

Earlier quoted context omitted.

You might be interested in this talk[0] by a WebKit engineer on how they're implementing similar approaches using libTooling and their own smart pointer types. For example, their tooling prevents code like this: if (m_weakMember) { m_weakMember->doThing(); } from compiling, forcing you to explicitly create an owning local reference, like so: if (RefPtr strongLocal = m_weakMember.get()) { strongLocal->doThing(); } unl…

I was going to link to this. My interpretation of Geoff's presentation is that some version of profiles might work, at least in the sense of making it possible to write C++ code that is substantially safer than what we have today.

Geoff's stuff is mostly about heuristics. For his purpose that makes sense. If Apple are spending say $1Bn on security problems and Geoff spends $1M cutting such problems by 90% that's money well spent. The current direction of profiles is big on heuristics. Easy quick wins to maybe get C++ under the "Radioactively unsafe" radar even if it can't pass for safe.

The most hopeful thing I saw in Geoff's talk was cultural. It sounds like Geoff's team wanted to get to safer code. Things went faster than expected, people landed "me too" unsolicited patches, that sort of thing. Of course this is self-reported, but assuming Geoff wasn't showing us a very flattering portrait of a grim reality, which I can't see any incentive for, this team sounds like while they'd get value from Rust they're delivering many of the same security benefits in C++ anyway.

Bureaucrats don't like culture because it's hard to measure. "Make sure you hire programmers with a good culture" is hard to chart. You're probably going to end up running some awful quiz your team hates "Answer D, A, B, B, E, B to get 100%". Whereas "Use Rust not C++" is measurable, team A has 93% of code in Rust, but team B scored 94.5% so that's more Rust, they win.

Re: Safe C++ proposal is not being continued

#69

Post by zozbot234 »

debo_ wrote: post #46
Animats wrote: post #39

Earlier quoted context omitted.

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they hav…

I think there is room for an ML with a modern toolchain story that just omits Rust's borrow checker and does something more boring. Typescript and Rust have primed a large number of developers to be open to it.

Isn't ReasonML pretty much that language already? Although the most popular language in that broader niche is probably Golang.

Re: Safe C++ proposal is not being continued

#70

Post by usefulcat »

vlovich123 wrote: post #49
Animats wrote: post #39

Earlier quoted context omitted.

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they hav…

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. I really don’t understand this perspective. The whole philosophy of Rust is one where you document why “unsafe” is safe. It is not and never has been a goal to make everything safe because that is an impossible goal to merge with high performance systems language because hardware itself is unsafe. It’s why the unsafe key…

If unsafe is not used, then no one has to determine whether the unsafe parts are actually safe.
Post reply on HN