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

Making C++ safe without borrow checking, reference counting, or tracing GC

verdagon.dev

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#211

Post by kaba0 »

mr_00ff00 wrote: post #113
ammar2 wrote: post #111

Earlier quoted context omitted.

Sure but you're missing the > so long as you are diligent about checking invariants part. Could you go through and check all the parts of a huge C++ codebase to make sure invariants are held as opposed to a few hundred lines of unsafe Rust code?

Sure, but I think the point here is the degree. Presumably if it takes a lot of unsafe rust lines to build something, it won’t matter if it’s 30% safe or whatever. I just see the point of “unsafe is fine” a lot when the whole point of rust is that memory safety issues are never worth the cost.

> whole point of rust is that memory safety issues are never worth the cost

I don’t think that it would be the point of rust — otherwise why not write Java, or a litany of GCd languages instead?

Rust is a low-level/systems programming language where you have more control over the program’s execution (e.g. no fat runtime), which is a necessity in some rare, niche, but important use cases.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#212

Post by kaba0 »

buildartefact wrote: post #164
amelius wrote: post #161

Earlier quoted context omitted.

> getting a mechanical check on memory safety for the price of some extra language verbosity is obviously worth it IMO But a GC'd language doesn't require the extra verbosity.

And you pay for that in performance

What performance? That’s not a single thing. Do you pay in throughput or latency?

It certainly has a price but it is waaay too overblown in many discussions. What it mostly does entail is a slightly larger p99 latency. Where it actually matters is entirely another question.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#213

Post by kaba0 »

gridspy wrote: post #162
kbenson wrote: post #63

Methods such as these for C and C++ are interesting, and needed, but only solve a part of the problem. As others have noted before, they do little good because they're opt-in. I think there's a bit of nuance to that which needs to be explored though, as I think it's less a problem that the extra checks are opt in, and more a problem of how we use and categorize libraries. As long as we encourage dynamic and static li…

Often missed here is that the Rust library author is strongly protected from faulty code written by Users. The C/C++ library author is not. The most obvious examples of this are memory allocation. The C/C++ user claimed the buffer was large enough to contain the result. The Rust user received back an object that protected the memory and returned it at the right time. But it could also be a file handle or mutex that u…

That’s a great point and I agree with it. Just to play a bit of a “devil’s advocate”, GCd languages productivity boost comes from exactly this: both in Rust (where it is explicit) and in other low-level languages, low-level design decisions leak into public API interfaces. It’s great that it is explicit in Rust, but depending on what you work on it may be better to just have the runtime deal with it. (But clearly the C-FFI API surface is the worse of implicit requirements that may not be uphold at all)

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#214

Post by orlp »

dxhdr wrote: post #208
orlp wrote: post #136

Earlier quoted context omitted.

> Slotmap uses unsafe everywhere, it's a memory usage pattern not supported by the borrow checker. Author of slotmap here. This is patently false. Yes, the slotmap crate uses a lot of unsafe to squeeze out maximum performance. But it is not 'a memory usage pattern not supported by the borrow checker'. You can absolutely write a crate with an API identical to slotmap without using unsafe.

> But it is not 'a memory usage pattern not supported by the borrow checker'. You can absolutely write a crate with an API identical to slotmap without using unsafe. I think that might actually be worse though, performance aside. You're performing memory / object lifetime management but the Rust borrow checker still would have no idea what's going on because now you've tricked it by using indices or an opaque handle…

Yes, using slotmap you can get "use after free"-style bugs that you would not encounter if you strictly stayed with the borrow checker. So if the borrow checker fits your purpose, by all means, go ahead.

But the borrow checker can't represent circular/self-referential structures you see very often in graphs. Nor is it convenient in some cases as it has a strict separation between references that can mutate, and those that can't, which doesn't fit all problems either because the mutable references are by necessity unique.

Note that a "use after free" in slotmap results in a None value, or a panic (exception for the C++ people), depending on which API you use. In other words, it is detected and you can handle it. It does not trigger undefined behavior, you don't get ABA-style spurious references, there are no security issues. It is not the same as the issues pointers have at all.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#215

Post by cyber_kinetist »

ChrisSD wrote: post #186
runeks wrote: post #180

Earlier quoted context omitted.

> "unsafe" just means "safe but the compiler cannot verify it". "unsafe" means "safe"? I would say "unsafe" means "only safe if used in a manner that cannot be checked by the compiler".

There are two things here. The `unsafe` in an `unsafe { ... }` block is referring to the contents of the block. From the outside it is indeed safe to use as if it were safe code. No special requirements necessary. So, yes, from a certain point of view `safe` would have been a better name (albeit confusing in a different way). An `unsafe fn` however does need to be used correctly (and should document those requirement…

Not entirely correct, Rust’s “unsafe” marker doesn’t pollute only its scope, it actually pollutes the whole module; You need to make sure that the invariants in unsafe code are met even in safe code. (An explanation of this in the Rustonomicon: https://doc.rust-lang.org/nomicon/working-with-unsafe.html)

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#216

Post by kbenson »

adamnemecek wrote: post #160
kbenson wrote: post #158

Earlier quoted context omitted.

Exactly. Presumably there are some opt-in tools that are very strict about the inline assembly uses you have in C. I don't have any experience with them, but I'm sure they exist. That's the whole point, it's less about the language, and more about the specifics of the code itself in a testable way. Saying something is written in C without accounting for a bunch of inline assembly is analogous to saying something is w…

There are no Rust crates with 95% unsafe code.

If you think I'm talking about rust vs C and not just using them as stand ins for any language pair, you're not understanding my point. Possibly because you're too focused on one language in particular, as I'm not focusing on any language in particular.

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#218

Post by verdagon »

saagarjha wrote: post #217
verdagon wrote: post #152

Earlier quoted context omitted.

You win =D

You didn’t delete it!

I know! I just couldn't bring myself to remove it it. It's such a cool note. I think I'm going to do these differently in the future lol

Re: Making C++ safe without borrow checking, reference counting, or tracing GC

#220

Post by int_19h »

SubjectToChange wrote: post #127
antonvs wrote: post #55

Earlier quoted context omitted.

> everything further out is playing with fire. That's the point. C and C++ don't prevent you from playing with that for. Memory-safe language do.

Rust only requires you to wrap it in unsafe. And I think C# allows you to do some pretty crazy stuff too.

C# cleanly separates pointers into Java-style managed references that are opaque, and C-style unmanaged pointers that are transparent but can only be used inside "unsafe" blocks.
Post reply on HN