...about whether pointer arithmetic is allowed to - temporarily - leave the bounds of an object, then go back into bounds and afterwards dereference the pointer.

The question is if code like this:

fn foo(x: &u8) {
    let mut x = x as *const u8;
    x = x.wrapping_add(42);
    x = x.wrapping_sub(42);
    let _val = unsafe { *x };
    // use _val
}

is sound or unsound.

The current documentation says:

The resulting pointer does not need to be in bounds, but it is potentially hazardous to dereference (which requires unsafe).

In particular, the resulting pointer remains attached to the same allocated object that self points to. It may not be used to access a different allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

Compared to add / sub / offset, this method basically delays the requirement of staying within the same allocated object: add / sub / offset is immediate Undefined Behavior when crossing object boundaries; wrapping_add / wrapping_sub / wrapping_offset produces a pointer but still leads to Undefined Behavior if that pointer is dereferenced. add / sub / offset can be optimized better and is thus preferable in performance-sensitive code.

So it specifies that the resulting pointer “remains attached to the same allocated object that self points to”, which suggests that after going back into bounds, dereferencing should be safe again.

It also says “this method basically delays the requirement of staying within the same allocated object; ” which sounds like, staying within the same allocated object is still a requirement, which could be interpreted as that whenever any intermediate value did not stay within bounds, that intermediate value has some delayed violation of requirements attached to it that triggers UB once the final (back in bounds) pointer is dereferenced.

The following comparison, “add / sub / offset is immediate Undefined Behavior when crossing object boundaries; wrapping_add / wrapping_sub / wrapping_offset produces a pointer but still leads to Undefined Behavior if that pointer is dereferenced” can easily be interpreted as confirming this interpretation, since object boundaries are crossed (twice, first going out of the object, then going back in) and the pointer is dereference afterwards (right after the second crossing of object boundaries).

After I was addressing this on IRLO, @RalfJung gave the answer

It is explicitly intended to be allowed to leave the object and then go back inbounds. Looks like we need to clarify the docs.

@rustbot modify labels: T-doc, T-libs, T-lang, C-enhancement
Feel free to remove a T- label if this doesn’t seem relevant for that team.