Visualizing memory layout of Rust's data types

youtube.com

31 points·eventhelix··2 comments

The Rust project seems to be understandably afraid to officially document the memory layout and get locked into supporting an ABI that might need to change at some point. The preference seems to be supporting extraction of data via library methods, but the project itself is moving quite slowly to support those as well.

It hasn't really been a major issue for me, but occasionally I've really wanted to get the vtable from a fat pointer and I've resorted to workarounds or just biting the bullet and using the de-facto standard layout that everyone knows (and statically asserting that it's a valid assumption for all types <T> that are used).

Note that pointer provenance can also break a lot of seemingly-valid assumptions too.

Understanding the layout of these types is helpful and useful, but keep in mind the caveat that these are technically subject to change.

Some fun reading links if this is interesting:

- https://github.com/rust-lang/rust/issues/75091

- https://github.com/rust-lang/rust/issues/81513

- https://github.com/rust-lang/rust/issues/95228

Couple of questions, which are because of my limited knowledge.

1) The pointer provenance you're referring to, is that CHERI or the pointer provenance currently in use in macOS?

2) Reading through your post, are you talking about the same as the anyhow's error implementation? https://github.com/dtolnay/anyhow/blob/af0937ef72fbaf9784a6c...

Reply on news.ycombinator.com