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

121–130 of 226 posts

Re: Safe C++ proposal is not being continued

#121

Post by pjmlp »

BoxFour wrote: post #21
quotemstr wrote: post #14

Earlier quoted context omitted.

You're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world. There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization. I don't think it's too late for…

> I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new. People have tried variants of this already: Carbon, for example. I don’t think anyone outside of Google uses it, though, and even within Google I suspect it’s dwarfed by regular C++. I don’t think C++ will become irrelevant for a long time. Recent standards have added some c…

Carbon is still being designed, and their goal is to migrate existing code, for Google purposes.

They are quite open everyone else should use a managed language or Rust.

Re: Safe C++ proposal is not being continued

#122

Post by WalterBright »

Voultapher wrote: post #102
WalterBright wrote: post #100

Earlier quoted context omitted.

> Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level. I'm familiar with borrow checkers, as I wrote one for D. Not following the rules of the borrow checker does not mean the program is flawed or incorrect. It just means the borrow checker is unable to prove it correct. > D lacks the most important and hardest kind of safety and that is reference safety I lo…

> I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem. Do you have good data on that? Looking at the curl and Chromium reports they show that use-after-free is their most recurring and problematic issue. I'm sure you are aware, but I want to mention this here for other readers. Reference safety extends to th…

No, I haven't kept track of the reports I've seen. They all had array bounds as the #1 error encountered in shipped code.

Edit: I just googled "causes of memory safety bugs in C++". Number 1 answer: "Buffer Overflows/Out-of-Bounds Access"

"Undefined behavior in C/C++ code leads to security flaws like buffer overflows" https://www.trust-in-soft.com/resources/blogs/memory-safety-...

"Some common types of memory safety bugs include: Buffer overflows" https://www.code-intelligence.com/blog/memory_safety_corrupt...

"Memory Safety Vulnerabilities 3.1. Buffer overflow vulnerabilities We’ll start our discussion of vulnerabilities with one of the most common types of errors — buffer overflow (also called buffer overrun) vulnerabilities. Buffer overflow vulnerabilities are a particular risk in C, and since C is an especially widely used systems programming language, you might not be surprised to hear that buffer overflows are one of the most pervasive kind of implementation flaws around." https://textbook.cs161.org/memory-safety/vulnerabilities.htm...

Re: Safe C++ proposal is not being continued

#123

Post by WalterBright »

IshKebab wrote: post #106
WalterBright wrote: post #74

Earlier quoted context omitted.

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

I think D failed to gain widespread traction for other reasons though: 1. The use of garbage collection. If you accept GC there are many other languages you can use. If you don't want GC the only realistic option was C++. Rust doesn't rely on GC. IIRC GC in D is optional in some way, but the story always felt murky to me and that always felt like a way of weaseling out of that problem - like if I actually started wri…

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.

Re: Safe C++ proposal is not being continued

#124

Post by Yoric »

tialaramex wrote: post #26
Yoric wrote: post #23

Earlier quoted context omitted.

> There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. Anecdotal, but that's hardly unique to C++. So even if C++ were to disappear overnight (which we all agree won't happen), this wouldn't be a burning-library-of-Alexandria moment.

Well. What other examples of this feat are you thinking of? To me the things which come to mind are either compiler magic (e.g. C printf) or they rely on RTTI (e.g. Odin and similar C-like languages) and neither of those is what fmt does, they're "cheating" in some sense that actually matters.

I co-implemented this in OCaml ~20 years ago, using no compiler magic (it did use a macro). Pretty sure that I've seen the equivalent in Haskell, too, and in variants of Scheme. Zig has it, too. And while, as you mention, the Rust implementation does use compiler magic, I'm pretty sure that it could be implemented as a macro, just more slowly.

etc.

Re: Safe C++ proposal is not being continued

#125

Post by astrobe_ »

Voultapher wrote: post #99
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…

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe…

> There is a prevalent culture of expecting users to not make mistakes.

I think the older of us C/C++ programmers come from no-safety languages like assembly language. That doesn't mean that all of us are "macho programmers" (as I was called here once). C's weak typing and compilers emitting warnings give a false sense of security which is tricky to deal with.

The statement you make is not entirely correct. The more correct statement is that there is a prevalent culture of expecting users to find strategies to avoid mistakes. We are engineers. We do what we need with what we have, and we did what we had to with what we had.

When you program with totally unsafe languages, you develop more strategies than just relying on a type checker and borrow checker: RAII, "crash early", TDD, completion-compatible naming conventions, even syntax highlighting (coloring octal numbers differently)...

BUT. the cultural characteristics of the programmers are only one-quarter of the story. The bigger part is about company culture, and more specifically the availability of programmers. You won't promote safer languages and safer practice by convincing programmers that it has zero impact on performance. It's the companies that you need to convince that the safe alternatives are as productive [1] as the less safe alternatives.

[1] https://xkcd.com/303/

Re: Safe C++ proposal is not being continued

#126

Post by Voultapher »

vintagedave wrote: post #114
Voultapher wrote: post #99

Earlier quoted context omitted.

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe…

A year or so ago I read that there was a design decision railroaded through the committee about what kind of safety approach could be looked at. Its wording effectively prevented Safe C++. I was not at this meeting so I’m going on what others say: https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4... I’m a big fan of Safe C++ and believe its approach — learning from another language, incremental opt-in (jus…

As much as the alternatives (profiles) don't solve the issue, Safe C++ (Circle) does have substantial issues as well. You need a separate and largely incompatible standard library, including containers. Generic code (templates) is largely left unsolved on a conceptual level so far. At this point incrementally replacing parts of your code with Rust - which has a mature ecosystem and tooling, remember if you want provable safety none of your dependencies used in Safe C++ code are allowed to be unsafe - is going to be less hassle. Firefox showed you can do it, and even Microsoft is choosing that path for the Windows kernel. Waiting for Safe C++ to be usable, seems like wanting to wait for a worse Rust. Interop is hardly going to be much better than bindings generated by cxx.

Re: Safe C++ proposal is not being continued

#127

Post by murderfs »

pjmlp wrote: post #108
jcranmer wrote: post #53

Earlier quoted context omitted.

C and C++ are fundamentally memory-unsafe languages. That doesn't make them bad languages, but it is a reality that you have to face when you work with them. And one of the things we've learned is that building safe abstractions, while not a complete solution, does quite a long way. And then CISA suggested that "maybe we should stop using memory-unsafe languages." And this has some of the C++ committee utterly terrif…

Spot on, since C++11 the committee has increasingly started to design and add features to the standard without any kind of implementation, only after the standard gets ratified, the implementers eventually find out that the design is broken, or has flaws. A strange phenomenon akin to the Algol 68 days, and no other ISO based language is taking, where standardising existing practice or having a full test implementatio…

The committee got burned, extremely badly, by C++03's export templates, where it got standardized without an implementation, and everyone realized it was basically unimplementable, and the only group that did, wrote a paper telling everyone not to [1]

This was well in mind when C++11 came around (especially since C++11 slipped so badly: it was originally "C++0x", and then they ran out of digits for x). By the time we hit C++20, I think the lessons were lost, especially when it came to there being two competing modules implementations and the committee deciding to select neither.

1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n14...

Re: Safe C++ proposal is not being continued

#128

Post by Voultapher »

astrobe_ wrote: post #125
Voultapher wrote: post #99

Earlier quoted context omitted.

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe…

> There is a prevalent culture of expecting users to not make mistakes. I think the older of us C/C++ programmers come from no-safety languages like assembly language. That doesn't mean that all of us are "macho programmers" (as I was called here once). C's weak typing and compilers emitting warnings give a false sense of security which is tricky to deal with. The statement you make is not entirely correct. The more…

I get the feeling you didn't watch my talk. The example in question is sorting. Say for example your comparison function does not implement a strict weak ordering, which can easily happen if you use In what world is the first preferable to the latter?

This behavior is purely an implementation choice. Even the C people glibc and LLVM libc consider this to be undesirable and are willing to spend 2-3% overhead on making sure you don't get that behavior.

No, this is not "expecting users to find strategies to avoid mistakes".

Re: Safe C++ proposal is not being continued

#129

Post by Voultapher »

WalterBright wrote: post #122
Voultapher wrote: post #102

Earlier quoted context omitted.

> I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem. Do you have good data on that? Looking at the curl and Chromium reports they show that use-after-free is their most recurring and problematic issue. I'm sure you are aware, but I want to mention this here for other readers. Reference safety extends to th…

No, I haven't kept track of the reports I've seen. They all had array bounds as the #1 error encountered in shipped code. Edit: I just googled "causes of memory safety bugs in C++". Number 1 answer: "Buffer Overflows/Out-of-Bounds Access" "Undefined behavior in C/C++ code leads to security flaws like buffer overflows" https://www.trust-in-soft.com/resources/blogs/memory-safety-... "Some common types of memory safety…

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 for humans, since it requires more context.

Re: Safe C++ proposal is not being continued

#130

Post by dminik »

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…

As far as I'm concerned, there are two main issues with profiles:

1. They're either unimplementable or useless (too many false positives and false negatives).

I think this is pretty evident based on the fact that profiles have been proposed for a while and that no real implementation exists. Worse, out of all of the open source projects and for profit companies, noone has been able to implement any sort of static analysis that would even begin to approach the guarantees Rust makes.

2. The language doesn't give you any tools to actually write safe code.

Ok, let's say that someone actually implements safety profiles. And it highlights your usage of a standard library type. What do you do?

Safe C++ didn't require a new standard library just because. The current stdlib is riddled with safety issues that can't really be fixed and would not be fixed because of backwards compatibility.

You're stuck. And so you turn the safety profile off.

Post reply on HN