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

71–80 of 226 posts

Re: Safe C++ proposal is not being continued

#71

Post by pizlonator »

tialaramex wrote: post #68
pizlonator wrote: post #34

Earlier quoted context omitted.

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…

> Geoff's stuff is mostly about heuristics.

That's not true at all.

- The bounds safety part of it prevents those C operations that Fil-C or something like it would dynamically check. You can to use hardened API instead.

- The cast safety part of it prevents C casts except if they're obviously safe.

- The lifetime safety part of it forces you to use WebKit's smart pointers except when you have an overlooking root.

Those are type safety rules. It's disingenuous to call them heuristics.

It is true, however, that Geoff's rules don't go to 100% because:

- There are nasty corners of C that aren't covered by any of those rules.

- WebKit still has - WebKit has JITs.

Re: Safe C++ proposal is not being continued

#73

Post by TuxSH »

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.

> For bounds checking, sure I think the performance penalty is so small that it can be done.

Depends on how many times it's inlined and/or if it's in hot code. It can result in much worse assembly code.

Funny thing: C++17 string_view::substr has bound check + exception throw, whereas span::subspan has neither; I can see substr's approach being problematic performance- and code-size-wise if called many times yet being validated by caller.

Re: Safe C++ proposal is not being continued

#74

Post by WalterBright »

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.

D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires.

These include:

1. bounds checked arrays (you can still use raw pointers instead if you like)

2. default initialization

3. static checks for escaping pointers

4. optional use of pure functions

5. transitive const and immutable qualifiers

6. ranges based on slices rather than pointer pairs

Re: Safe C++ proposal is not being continued

#75

Post by worthless-trash »

pklausler wrote: post #32
tialaramex wrote: post #20

Earlier quoted context omitted.

Well like you said, Fortran didn't actually go anywhere. Fortan 77 is a terrible programming language, but you can't seriously claim it "disappeared from the Earth". Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do. There are a few really amazing thi…

Judging Fortran by looking at Fortran 77 is preposterously uninformative.

What should we be looking at ?

Re: Safe C++ proposal is not being continued

#76

Post by jmull »

IAmLiterallyAB wrote: post #41
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…

My limited understanding is. There is no safe subset (That's what was just discontinued, profiles are the alternative.) And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html

The analysis you link to is insufficient.

E.g., the first case is "Inferring aliasing". He presents some examples and states, "The compiler cannot infer a function’s aliasing requirements from its declaration or even from its definition."

But why not?

The aliasing requirements come directly from vector. If the compiler has those then determining the aliasing requirements of those functions is straightforward.

Now, maybe there is some argument that a C++ compiler cannot determine the aliasing requirements of vector, but if that's the claim, then the paper should make it, and back it up.

The paper continues in the same vein in the next section, as if the lifetime requirements of map and min cannot be known or cannot bubble up through the functions that call them.

As written, the paper says almost nothing about the feasibility of static analysis of C++ to achieve safety goals for C++.

Re: Safe C++ proposal is not being continued

#77

Post by Rusky »

pizlonator wrote: post #36
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…

> 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…

If that is what profiles were actually doing, it would probably make sense. But it's not what profiles are doing.

Instead, for example, the lifetime safety profile (https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...) is a Rust-like compile time borrow checker that relies on annotations like [[clang::lifetimebound]], yet they also repeatedly insist that profiles will not require this kind of annotation (see the papers linked from https://www.circle-lang.org/draft-profiles.html#abstract).

Their messaging is just not consistent with the concrete proposals they have described, let alone actually implemented.

Re: Safe C++ proposal is not being continued

#78

Post by vlovich123 »

usefulcat wrote: post #70
vlovich123 wrote: post #49

Earlier quoted context omitted.

> 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.

Sure, but taken to an extreme you see the absurd degree you have to contort yourself. And that’s to the current version of the proof checker - some unsafe’s are even only temporary until a better prover comes by.

You shouldn’t go out of your way to use unsafe, but between that and 2 weeks refactoring, I’ll take the unsafe and use tools like miri or ASAN to provide extra guards. Engineering is inherently about making practical choices.

Re: Safe C++ proposal is not being continued

#79

Post by westurner »

Rust then?

From "The state of Rust trying to catch up with Ada [video]" https://news.ycombinator.com/item?id=43007013 :

> [awesome-safety-critical]

> rustfoundation/safety-critical-rust-consortium: https://github.com/rustfoundation/safety-critical-rust-conso...

rust-lang/fls: https://github.com/rust-lang/fls

How does what FLS enables compare to these Safe C++ proposals?

Safe C++ draft: https://safecpp.org/draft.html

Re: Safe C++ proposal is not being continued

#80

Post by slavik81 »

worthless-trash wrote: post #75
pklausler wrote: post #32

Earlier quoted context omitted.

Judging Fortran by looking at Fortran 77 is preposterously uninformative.

What should we be looking at ?

If we're judging the state of Fortran in 2025, we should probably be discussing Fortran 2018 or Fortran 2023.
Post reply on HN