Conversation

Why can't you just add a lifetime analysis/borrow checker to your favorite memory-unsafe language? Because Rust's static analysis does just one thing: makes sure you're following Rust's rules. But you aren't following those rules. So it won't work.

155

Patrick Walton

@pcwalton

Nov 14, 2021

What people who say they want a borrow check for C/C++/Zig/etc really want is a system that will automatically achieve memory safety without giving the programmer strict rules to follow. That technology exists and is very mature: garbage collection.

229

Tony "Abolish ICE" Arcieri

@bascule

Nov 14, 2021

Replying to

@pcwalton

…except for the part where pretty much all GC’d languages support mutable aliasing across threads

Replying to

and

Java does maintain memory safety despite having shared mutable state. Every field in Java would be considered atomic in C++11 or Rust but with an even weaker memory ordering than relaxed: llvm.org/docs/Atomics.h It doesn't do any more than preserving memory and type safety.

Replying to

and

Java has data races in the same sense that Rust has data races via atomics. It's not the kind of data race you get in C where it's totally unsafe with no guarantees and memory/type safety exists despite it. Java didn't take the shortcut that Go did where races can corrupt memory.

Replying to

and

Technically yeah, but the fact that Rust requires you to opt in to making values atomic (as opposed to Java where you can't even opt out) makes a big difference in practice.

Replying to

and

I don't think there is much hardware these days that don't follow the "no writes coming from nowhere" and "no reading half-updated values" rules which make broken Java/Go/etc code still memory-safe. Also IIRC one opts-in with volatile or AtomicType...

Replying to

and

Go has multi-word values for slices and maps which are unsafe in the presence of data races. It may go beyond that too. Java enforces safety in the presence of data races. It has pervasive opportunities for races but the runtime / standard library have to preserve safety.

Replying to

and

"unsafe" as in it could crash, or that you could read stray pointers and go into UB land? Coming from Java (not that I've written a lot, admittedly) it seems odd that races would do the latter, given that you don't read half-updated pointers, and the GC still traces through.

Replying to

and

Data races can corrupt memory in Go. Slices have a pointer, length and capacity without synchronization and perform direct memory access. It's possible for a race to cause an out-of-bounds access to be permitted. Maps have the same kind of issue too.

1:58 AM · Nov 14, 2021Twitter Web App

Replying to

As opposed to getting an out-of-bounds access panic, it can permit the out-of-bounds read or write due to a data race and corrupt memory. It can get a bit more complicated than that too. It's probably not going to happen much in practice but an attacker could trigger it...

Replying to

There are often seemingly nearly impossible to exploit memory corruption bugs in C particularly those involving data races where an attacker still figures out how to exploit it. They can attempt to trigger conditions where it becomes more likely to succeed and can often retry.

Show replies

Replying to

and

Well, must suck to write Go then. ):