Hacker News Reader

Comment by mwkaufma | Hacker News Reader

> Handles are deterministic. If a bug made your program crash on the last run, it will crash the same way on this run.

> Given that the arena will still be subject to array bounds checking, handle bugs won't allow an attacker to overwrite arbitrary memory the way pointer bugs do.

Just because you're in-bounds of the arena, doesn't mean you're not stomping on in-bounds neighboring data -- which can introduce "nondeterminism" as the author defines it. These are hand-waving arguments.

View on HN

> doesn't mean you're not stomping on in-bounds neighboring data

I don't see how you would do that in safe rust though. The point of the arena would just be to solve the lifetime issue. It just moves the ownership problem one level higher. Instead of having circular ownership in a linked list, all linked list nodes are owned by the arena and hence have the same lifetime as the arena.

It's not just linked lists. From the article:

> The next step of course is to write your own equivalents of malloc and free to allocate and deallocate objects within the arena.

A logic bug in that "allocator" - which are plain indices and not covered by borrow checking - could 100% stomp memory.

Sure, any program can have bugs. The point though is that it is "just a bug" and not UB.

Anticipating pushback: yes, you can disallow "pointer arithmetic" on handles, and store fingerprints in the "slots" to ensure they still contain the handle's identity to detect user-after-free, but congrats, you've implemented sparse sets, which there are dozen's of C++ implementations of with the same safety guarantees, so it's unclear what rust is bringing in that case (e.g. https://github.com/skypjack/entt/blob/master/src/entt/entity...)

That C++ already has many implementations of sparse sets seems to be a point in favor of sparse sets rather than a point against Rust, especially given that C++ doesn't need them the same way Rust does.

Well, there's several implementations because it's a bit of a leaky abstraction, and implementation details matter/vary across use-cases, which is consistent w/ my experience of rust having heavy fragmentation in applying the array-index pattern for "weak pointers."

If only devs had any other reason to use Rust.....

The topic is "Arenas in Rust" not "Arenas in Rust or anything other tradeoff."

Indeed, the topic is "in Rust", so you'd do arenas in Rust due to those memory safety benefits outside of arenas. And since arenas aren't as bad due determinism etc, it's still a net benefit: safer outside, safer inside

stomping on in-bounds data might result in "nondeterminism", but bounded and not ub, which is unbounded.

Reply on news.ycombinator.com