Tracking issue for ptr::offset_from (feature: ptr_offset_from)

[Amanieu]

PR: #40943

Adds an offset_to method to calculate the distance between two raw pointers.

List o' stuff:

• Rename to offset_from and make unsafe (with wrapping_offset_from for the safe one) Tracking issue for ptr::offset_from (feature: ptr_offset_from) #41079 (comment) -- done in Introduce unsafe offset_from on pointers #49297
  • Should offset_from abort instead of panic on ZSTs?
• Given that the difference between arbitrary pointers is meaningless and subject to change at the whims of LLVM anyway, do we even want the safe version? Tracking issue for ptr::offset_from (feature: ptr_offset_from) #41079 (comment) Experience reports from the field appreciated.
• Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)
• Ensure that our safety requirements align with the proposed llvm.psub [LLVM9+] Use llvm.psub in offset_from #57818

[scottmcm]

I wonder whether this should have the unsafe + wrapping_ split that offset does.

The unsafe one could, for example, use sdiv exact by requiring that the pointers are to the beginning or past-the-end of real objects inside the same allocated object.

[strega-nil]

It seems suspicious at best to calculate the offset between two unrelated pointers... I agree with @scottmcm

[joshtriplett]

@pornel made the point that this should be offset_from, with the order of the subtraction reversed, which I agree with. (Or, perhaps, both methods should exist.)

[joshtriplett]

Also, I find it unfortunate that this forces handling the ZST case even if you know the pointer type and know that it doesn't point to a zero-sized type.

Could we use traits to provide a method that only exists for non-zero-sized types, and then returns isize?

[sunfishcode]

I like @scottmcm's suggestion to have an unsafe ptr::offset_to that uses sdiv exact. This is the situation sdiv exact was designed for, and it often reduces a 5-instruction sequence down to 2. And, if the unsafe version could be documented to have UB if the pointers don't point into the same array (or one-past-the-end), it would make me less worried about breaking pervasive assumptions that LLVM makes about pointer differences [0]. And it would be sufficient for Vec and related use cases.

I suggest omitting the wrapping_ form though. Even if the implementation is entirely "safe" code, I agree with @ubsan that it's suspicious at best and doesn't seem like the kind of thing that should be encouraged via a convenient standard library function.

[0] For example, GetUnderlyingObject, which is used throughout the optimizer, assumes that getelementptr X, Y aliases a subset of X. This doesn't work if Y can be the difference from X to an independent object.

[iitalics]

I think that returning None for the zero-sized-type case is unnecessary. It is a very unlikely event, and a majority of the time the user knows they will never get the None case, so unwrapping is just clutter.

[SimonSapin]

Renaming to offset_from and swapping the subtraction order seems easy enough.

I don’t really understand the unsafe / sdiv exact aspect, though. I’ll leave that decision to someone else.

@Amanieu since you added this, what do you think?

[Amanieu]

I have no objection to renaming it to offset_from.

The unsafe / sdiv exact issue basically boils around one question: what happens if the distance between the two given pointers is not a multiple of sizeof_of::<T>(). There's only 2 ways we can realistically handle this:

• Make this situation UB (in which case offset_from becomes an unsafe function).
• Round the result of the division towards zero.

The current implementation rounds towards zero, however I am considering going with the UB route instead. Note that this situation can only happen if one of the pointers is misaligned, so we could just require that both pointers be properly aligned for their type.

[SimonSapin]

this situation can only happen if one of the pointers is misaligned

Can’t it also happen with aligned pointers, if size_of::<T>() > align_of::<T>()?

[Amanieu]

That's a good point, I'm not sure why I thought of alignment there. You are correct.

[sunfishcode]

@SimonSapin That's a good point. C manages to avoid that issue, because in C it's undefined behavior if the pointers aren't both pointing to elements of the same array (6.5.6p9). I don't know whether Rust's offset_from wants a similar rule, though you can get into dangerous territory with pointer aliasing if you access one object using a pointer to another plus the distance between the two.