Live data from Hacker News

Safe C++ proposal is not being continued

sibellavia.lol

221–226 of 226 posts

Re: Safe C++ proposal is not being continued

#221

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

Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you…

> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.

How so? By listing all dependencies in an easy to digest way?

Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it.

"Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done.

Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository).

Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there.

> Currently I see no existential risk at all.

I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed.

When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.

Re: Safe C++ proposal is not being continued

#222
post #91

Earlier quoted context omitted.

> You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python". I don't see how that follows at all. What makes Python Python (and slow!) is dynamic dispatch everywhere down to the most primitive things. Refcounted smart pointers are a very minor thing in the big picture, which is why we've seen Python implementations without them…

> Jython, IronPython Both of which have modern, concurrent, parallel, and generational garbage collectors.

When you wrote "smart pointers" I naturally assumed refcounting specifically. If you include traced GC references in this category, then sure. Although even then languages like Java and Go are much closer in their performance to C++ than to Python, so even with this definition it's an odd comparison.

Re: Safe C++ proposal is not being continued

#223
post #91

Earlier quoted context omitted.

> You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python". I don't see how that follows at all. What makes Python Python (and slow!) is dynamic dispatch everywhere down to the most primitive things. Refcounted smart pointers are a very minor thing in the big picture, which is why we've seen Python implementations without them…

Python doesn't have lvalues in the way that C++ and Rust do. You can't refcount everything and still pass lvalues to subobjects. If lvalues to subobjects are important, you need borrow checking.

Yes, which is why I mentioned C# "ref" which is not refcounting but zero-overhead pointers with a simplistic borrow checker that covers most practical scenarios.

Re: Safe C++ proposal is not being continued

#224
post #88

Earlier quoted context omitted.

Most of those abstractions and baggage come from the need to be able to represent and propagate lifetime constraints, though.

proc macros? Optional?

I would agree with macros, but I'm pretty sure that people who want borrow checking are not the ones who'd describe optionals as "baggage".

Re: Safe C++ proposal is not being continued

#225
post #89

Earlier quoted context omitted.

https://doc.rust-lang.org/std/macro.format.html https://zig.guide/standard-library/formatting/

Rust is an example of "compiler magic" in this case. You're right about Zig, and reading the source [1] I'm still kind of impressed how unified they made comptime / runtime. [1]: https://github.com/ziglang/zig/blob/32a1aabff78234b428234189...

"Compiler magic" is generally used to describe things that are built into the compiler; I don't see why macros would qualify. And if they do, then why wouldn't template metaprogramming?

Re: Safe C++ proposal is not being continued

#226

Earlier quoted context omitted.

Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you…

> Normally no one talks anymore about things like buffer overflows, use after free,... since years Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.

> > Normally no one talks anymore about things like buffer overflows, use after free,... since years

> Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access.

If I understand the Heartbleed bug correctly, it did not involved buffer overflows. It was a logical bug where they "trusted" the user-provided payload length (that can be much larger than the actual payload) and allocated the response buffer accordingly without zeroing it (malloc vs calloc). The "trash" in the uninitialized memory turned out to be quite valuable.

"xkcd: Heartbleed Explanation":

https://xkcd.com/1354/

"Add heartbeat extension bounds check.":

https://github.com/openssl/openssl/commit/731f431497f463f3a2...

Post reply on HN