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

Why Safety Profiles Failed

circle-lang.org

Post reply on HN
Print view View original

41–50 of 233 posts

Re: Why Safety Profiles Failed

#41

Post by SubjectToChange »

wyager wrote: post #35
SubjectToChange wrote: post #12

Earlier quoted context omitted.

Things like web browsers will continue to have millions of lines of C++ code regardless of how successful Rust becomes. It would be a huge improvement for everyone if such projects had a tractable path towards memory safety

As this article discusses, it's not really viable that existing codebases will be able to benefit from safe C++ research without massive rewrites anyway

Yes, absolutely. But it is still easier and more practical for those codebases to write new functionality in a Safe C++ dialect than it would be to use Rust.

Re: Why Safety Profiles Failed

#42

Post by ameliaquining »

SubjectToChange wrote: post #10

At this point I'm wondering if the purpose of safety profiles is simply to serve as a distraction. In other words, safety profiles are just something people can point to when the topic of memory safety comes up, that’s it. The objectives of the initiative always seemed hopelessly optimistic, if not absurd. In particular, I don't understand why littering a codebase with auto, const, constexpr, inline, [[nodiscard]], n…

I think maybe it's because lifetime annotations can get arbitrarily complicated. If you look at enough Rust code you'll definitely see some function signatures that make your head hurt, even if they're vastly outnumbered by simple ones. A guarantee that the comprehension complexity of that part of your code will always be below some low ceiling is tempting.

Re: Why Safety Profiles Failed

#43

Post by ameliaquining »

pavon wrote: post #38
wyager wrote: post #32

Earlier quoted context omitted.

> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.

Why not? C++ has evolved over the years, and every C++ project I have worked on, we've adopted new features that make the language safer or clearer as they are supported by the compilers we target. It doesn't get applied to the entire codebase overnight, but all new code uses these features, refactors adopt them as much as possible, and classes of bugs found by static code scanning cause them to be adopted sprinkled…

What I'm really hoping is that https://github.com/google/crubit eventually gets good enough to facilitate incremental migration of brownfield C++ codebases to Rust. That seems like it would address this concern.

Re: Why Safety Profiles Failed

#44

Post by bfrog »

favorited wrote: post #30

I know Sean said on Twitter that he probably won't submit this to WG21, but I wish he would... It is a fantastic rebuttal of certain individual's continued hand-waving about how C++ is safe enough as-is.

This seems to be a common theme with many c++ developers honestly.

Re: Why Safety Profiles Failed

#45

Post by tptacek »

wyager wrote: post #33
tptacek wrote: post #6

Earlier quoted context omitted.

This is a thread about a C++ language feature; it's probably most productive for us to stipulate for this thread that C++ will continue to exist. Practical lessons C++ can learn moving forward from Rust are a good reason to talk about Rust; "C++ should not be improved for safety because code can be rewritten in Rust" is less useful.

Actually, this subthread is about whether this is a "really important project"

to the C++ language

Re: Why Safety Profiles Failed

#46

Post by o11c »

steveklabnik wrote: post #28
o11c wrote: post #13

Earlier quoted context omitted.

Dealing with malloc/free is trivial and cheap - just give every allocated object a couple of reference counts. The hard part is figuring out which words of memory should be treated as pointers, so that you know when to alter the reference counts. Most C programs don't rely on all the weird guarantees that C mandates (relying on asm, which is also problematic, is probably more common), but for the ones that do it is q…

The borrow checker works irrespective of the heap. Memory safety involves all pointers, not just ones that own a heap allocation.

If we're trying to minimize annotation while maximizing C compatibility, it will be necessary to heap-allocate stack frames. This cost can be mitigated with annotations, once again. In this case, a global "forbid leaks even if unused" flag would cover it.

Static allocations only need full heap compatibility if `dlclose` isn't a nop.

And TLS is the forgotten step-child, but at the lowest level it's ultimately just implemented on normal allocations.

Re: Why Safety Profiles Failed

#48

Post by whimsicalism »

ameliaquining wrote: post #42
SubjectToChange wrote: post #10

At this point I'm wondering if the purpose of safety profiles is simply to serve as a distraction. In other words, safety profiles are just something people can point to when the topic of memory safety comes up, that’s it. The objectives of the initiative always seemed hopelessly optimistic, if not absurd. In particular, I don't understand why littering a codebase with auto, const, constexpr, inline, [[nodiscard]], n…

I think maybe it's because lifetime annotations can get arbitrarily complicated. If you look at enough Rust code you'll definitely see some function signatures that make your head hurt, even if they're vastly outnumbered by simple ones. A guarantee that the comprehension complexity of that part of your code will always be below some low ceiling is tempting.

Rust has nothing on template meta programming and the type signatures you get there, though

Re: Why Safety Profiles Failed

#49

Post by morning-coffee »

o11c wrote: post #7

"No mutable aliases" is a mistake; it prevents many useful programs. Now that virtual address space is cheap, it's possible to recompile C (or presumably C++) with a fully-safe runtime (requiring annotation only around nasty things like `union sigval`), but this is an ABI break and has nontrivial overhead (note that AddressSanitizers has ~2x overhead and only catches some optimistic cases) unless you mandate addition…

> "No mutable aliases" is a mistake; it prevents many useful programs.

Yes, it prevents many useful programs.

I think it also prevents many many many more useless broken incorrect programs from wreaking havoc or being used as exploit delivery vehicles.

Re: Why Safety Profiles Failed

#50

Post by steveklabnik »

zahlman wrote: post #47

What actually is this circle-lang site, and who runs it? The main page seems to just redirect to example.com, and I don't recognize the name of the author.

Circle is a C++ compiler by Sean Baxter, with various extensions. One of those is an implementation of the Safe C++ proposal I’ve linked downthread.
Post reply on HN