constrain safety preconditions of layout_for_ptr functionality

[jswrenn]

This commit implements the recommendation of #69835 (comment) to make the safety preconditions of the raw pointer layout utilities more conservative, as to ease the path towards stabilization. In the future, we may (if we choose) remove some of these restrictions without breaking forwards compatibility.

[rustbot]

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

[thomcc]

This feels like it's not a question for me.

r? @rust-lang/opsem

[CAD97]

The noted comment suggests to

add a safety precondition that the pointer not result in size wrapping [to size_of_val_raw and friends]

but this is already the case, as the docs say that the size of the entire value must fit in isize. What this PR adds, that

the pointer plus the size must not overflow the address space

is a completely different requirement. (Plus, ptr.wrapping_byte_offset(size) is the one-past-the-end pointer; there's no benefit to mentioning it separately.)

See my reply in the tracking issue for more context.

[jswrenn]

@CAD97, ah, I misunderstood what you meant by 'wrap'. Yes, I agree, the size wrapping constraint is already covered. Still, it is possible to use ptr::slice_from_raw_parts to overflow the address space without overflowing the size, and addressing this possibility seems useful.

[RalfJung]

See the discussion here -- I don't think we should do this. We should allow raw ptr size-of for non-dereferenceable pointers.

[jswrenn]

@RalfJung, as far as I can tell, the safety preconditions here do not generally require dereferenceability. The one exception is that the vtable part of a dyn pointer must point a valid vtable.

[CAD97]

Dereferencability specifically is more in respect to my proposed conservative wording in the tracking issue, but the sentiment holds the same for the change here: that there should be no restrictions placed by these *_raw methods on the address part of the pointer (for unsized tails of currently stable kinds).

I plan to make a PR sometime next week rewording/refining the current requirements and to propose T-lang FCP signoff on stabilizing that capability. I expect no lang concerns; I just haven't had the time/motivation to push for it yet.

As such, I'd suggest closing this PR as not planned. If T-lang requests a more conservative option in their FCP, we can reopen and/or otherwise pivot.

[jswrenn]

Happy to close, then. Let me know if there's anything @joshlf and I can do to help drive this forward. The stabilization of size_of_val_raw the major blocker for landing support of safer transmutation of DSTs into zerocopy.

[joshlf]

Does that include that there should be no restrictions on the vtable pointer, or is the vtable pointer the one exception (ie, it will be required to point to a valid vtable entry, and perhaps one whose metadata is such that the pointer encodes a value whose size fits in isize)? If the vtable pointer can also be invalid, what is the behavior if called with an invalid vtable pointer?

[CAD97]

The current docs are the semantics I intend to FCP — the ptr.addr() part is irrelevant, but the ptr.meta() part is extremely important. IIRC, T-lang has FCPd vtable pointer validity as (at least) a safety invariant of fat pointers to dyn Trait tails, allowing trait upcasting raw pointers (feature(trait_upcast)). It's also a safety invariant of ptr::DynMetadata) (feature(ptr_metadata)). It will also be a safety precondition of layout_of_value_raw, though whether that's better spelled out or left implicit is a docs call I'm not quite worrying myself with yet (I'm focusing on just getting the semantics approved first). (Making it an explicit safety precondition might accidentally imply that it's not an implicit safety precondition to all other functions that don't explicitly remove the precondition.)

[RalfJung]

Does that include that there should be no restrictions on the vtable pointer, or is the vtable pointer the one exception (ie, it will be required to point to a valid vtable entry, and perhaps one whose metadata is such that the pointer encodes a value whose size fits in isize)?

Currently, the vtable pointer being valid is part of the validity invariant of dyn Trait-tailed raw pointers. So it is UB to even construct a raw ptr with a bad vtable. Therefore, the raw align/size-of methods can rely on the vtable pointer being valid.

This might be relaxed in the future to only be a safety invariant, but can't be relaxed further as @CAD97 noted.