undefined | Better HN

0 pointsoneshtein1y ago0 comments

For Rust references, rules[0] are not hard to follow:

The pointer must be properly aligned.

It must be non-null.

It must be “dereferenceable”: a pointer is dereferenceable if the memory range of the given size starting at the pointer is entirely contained within the bounds of that allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

The pointer must point to a valid value of type T.

When creating a mutable reference, then while this reference exists, the memory it points to must not get accessed (read or written) through any other pointer or reference not derived from this reference.

When creating a shared reference, then while this reference exists, the memory it points to must not get mutated (except inside UnsafeCell).

[0]: https://doc.rust-lang.org/stable/core/ptr/index.html#pointer...

0 comments

mk121y ago

One reason it’s harder to follow is you can’t have references to uninitialized memory. In Zig pointers to uninitialized memory are fine as long as you don’t dereference them. That’s also true of Rust’s raw pointers, but most Rust code uses references, so it can’t be reused in unsafe contexts.

As a concrete example, I previously used Vec in unsafe code that dealt with uninitialized memory. This should be fine because Vec is basically a raw pointer and two integers. But later they changed the docs to say that this was undefined behavior (essentially, Vec reserves the right to “produce” a reference whenever it wants, even if you avoid calling methods that would do that). So my code that previously followed the rules now appeared to violate them.

1 more reply

j / k navigate · click thread line to collapse

0 comments

mk121y ago

1 more reply

j / k navigate · click thread line to collapse