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

151–160 of 226 posts

Re: Safe C++ proposal is not being continued

#151

Post by fulafel »

MattDamonSpace wrote: post #85
usamoi wrote: post #58

They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.

I work on a Swift/iOS app that wraps a C++ library 90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this. Please tell me my options aren’t limited to “please be better at programming”…?

Does iOS let you run it in another process? That's a common technique to isolate your app from crashy 3rd party components. This can work if you don't pass it untrusted data. If there's untrusted data coming in and you give it to a crashy c++ component, you're just asking to be pwned.

For containing legacy C++ codebases https://fil-c.org/ looks promising as well, and could fit the bill better if the data was user supplied. It's been discussed on HN many times, most recently here https://news.ycombinator.com/item?id=45133938 .. but currently doesn't support iOS.

Re: Safe C++ proposal is not being continued

#152

Post by krater23 »

MattDamonSpace wrote: post #85
usamoi wrote: post #58

They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.

I work on a Swift/iOS app that wraps a C++ library 90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this. Please tell me my options aren’t limited to “please be better at programming”…?

Sorry, but yes, when your app crashes there could be two issues. The C++ library that you use is shit, or your engineers don't understand the underlying concept of allocating/deallocating things because for Swift they had never to learn them. With Rust the code just wouldn't compile at all, that the only difference.

Re: Safe C++ proposal is not being continued

#153

Post by Measter »

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…

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

Re: Safe C++ proposal is not being continued

#154

Post by Hendrikto »

zozbot234 wrote: post #67
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. 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 borro…

> Rust just shifts the effort earlier in the development phase […]. You may spend a few hours struggling with the borrow checker.

And by the time you got it figured out, the requirements change, and you’re back to struggling with the borrow checker.

> that saves you countless days of debugging highly non-trivial defects, especially in a larger codebase.

Seems like many projects never get to the point where the architecture toil pays off. Instead, they spend 80–90% of their time trying to find the perfect architecture, which is then brittle against change.

Re: Safe C++ proposal is not being continued

#155

Post by Measter »

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?

You've misunderstood what Steve is saying, and what safe/unsafe means in Rust. In Rust, if I have a block of code that doesn't use any operations that require the unsafe keyword, then I am guaranteed (modulo compiler bugs) that this block of code is free of all undefined behaviour.

It does not guarantee that code in any function being called within that block is free of it, but it does guarantee this block of code is.

Profiles don't give you that.

Re: Safe C++ proposal is not being continued

#156

Post by Voultapher »

IshKebab wrote: post #144
Voultapher wrote: post #129

Earlier quoted context omitted.

Spatial safety can be achieved exhaustively with a single compiler switch - in clang - and a minor performance hit. Temporal safety is much harder and requires software redesign, that's why it still remains in projects that care about memory-safety and try over a long time to weed out all instances of UB, i.e. critical software like curl, Linux and Chromium. Temporal safety is usually also much harder to reason about…

What flag is that? Address sanitizer has a 2x performance hit so presumably not that?

-fbounds-safety [1]

Based on their slides [2]. I was wrongly informed one does need to do some light annotation in function signatures and struct definitions for anything ABI relevant. Based on their slides:

Ptrdist and Olden benchmark suites

- LOC changes: 2.7% (0.2% used unsafe constructs) Much lower than prior approaches

- Compile-time overhead: 11%

- Code-size (text section) overhead: 9.1% (ranged -1.4% to 38%)

- Run-time overhead: 5.1% (ranged -1% to 29%)

Measurement on iOS

- 0-8% binary size increase per project

- No measurable performance or power impact on boot, app launch

- Minor overall performance impact on audio decoding/encoding (1%)

[1] https://clang.llvm.org/docs/BoundsSafety.html

[2] https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...

Re: Safe C++ proposal is not being continued

#157

Post by seanbax »

I would have implemented profiles if profiles had a chance of working. But they will not ever work. I present many examples of why they fail here: https://www.circle-lang.org/draft-profiles.html

People who say Profiles are a path forward, please address any of the points in this document.

Re: Safe C++ proposal is not being continued

#158

Post by destroycom »

IshKebab wrote: post #143
WalterBright wrote: post #123

Earlier quoted context omitted.

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. D has a lot of very useful features. Memory safety features are just one aspect of it. > The awkward standard library schism. ??? Don't underestimate the backing of a large and powerful organization.

> You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. Yes but people wanted a language where you can't use GC. > ??? "Which standard library should I use?" is not a question most languages have: https://stackoverflow.com/q/693672/265521 Surely... you were aware of this problem? Maybe I misunderstood the "???". > Don't underestimate the backing of a large a…

> "Which standard library should I use?" is not a question most languages have: > https://stackoverflow.com/q/693672/265521

There is no such question when using D2 either. It was only an issue with D1, which was discontinued almost 15 years ago and was irrelevant for longer.

Re: Safe C++ proposal is not being continued

#159

Post by pron »

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…

> Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads".

Or, for even better performance, you can use Java (24+), which has both "green threads" and a more advanced and performant GC and compiler than Go.

Re: Safe C++ proposal is not being continued

#160

Post by DannyBee »

IshKebab wrote: post #33
AlotOfReading wrote: post #30

Earlier quoted context omitted.

It doesn't show up in the online videos, but there was a huge contingent of people at that fireside chat wanting a reasonable safety story for C++. The committee simply doesn't have representation from those people and don't seem to understand why it's an existential risk to the language community. The delivery timelines are so long here that anything not standardized soon isn't going to arrive for a decade or more.…

Yeah because the committee is now people that a) really love C++, and b) don't care enough about safety to use Rust instead. I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.

“But those people aren't going to join language committees.”

This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential

Post reply on HN