Repository navigation
ptr::offset should explicitly clarify 0-sized offset semantics #65108
Description
https://doc.rust-lang.org/std/primitive.pointer.html#method.offset
I can't remember the past arguments we definitely had about this, but it would be nice to explicitly call out the answer in the docs.
As a relevant example, Vec::into_iter currently unconditionally computes the "end" pointer of the array by offsetting by len (as long as size_of T > 0). This means that we offset a dangling pointer by 0 when iterating an empty Vec. This is obviously useful to support and annoying to have to guard against, so I would hope that's well-defined.
https://doc.rust-lang.org/src/alloc/vec.rs.html#1860
fn into_iter(mut self) -> IntoIter<T> {
unsafe {
let begin = self.as_mut_ptr();
let end = if mem::size_of::<T>() == 0 {
arith_offset(begin as *const i8, self.len() as isize) as *const T
} else {
// SAFE when `begin` dangles and `len == 0`???
begin.add(self.len()) as *const T
};
let cap = self.buf.capacity();
mem::forget(self);
IntoIter {
buf: NonNull::new_unchecked(begin),
phantom: PhantomData,
cap,
ptr: begin,
end,
}
}
}
Activity
Gankra commentedon Oct 4, 2019
cc @RalfJung
Gankra commentedon Oct 4, 2019
(For anyone driving by, the ZST branch is an irrelevant distraction. We guarantee ZST ops do nothing, and this code is specially making the offset non-zero so it can use the pointer difference as a counter.)
RalfJung commentedon Oct 9, 2019
The problem is that we don't really know what LLVM's rules are for
getelementptr inboundswith a 0 offset. Also see #54857 of which this seems to be a duplicate, the corresponding UCG issue rust-lang/unsafe-code-guidelines#93, and this thread (spread across 3 months) on the LLVM list:https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html, https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html, https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html.
What Miri currently implements is the most restrictive version that allows current code to work: if you cast an int to a ptr, you may offset that by 0 and it's okay unless that int is 0 (NULL ptrs are special). If you have a "real" pointer, you may only offset it by 0 if it is inbounds of an allocation. With ptr-int-casts this distinction between "real pointers" and integer pointers gets blurry, however...
Auto merge of rust-lang#117329 - RalfJung:offset-by-zero, r=oli-obk,s…
Auto merge of rust-lang#117329 - RalfJung:offset-by-zero, r=oli-obk,s…
Auto merge of #117329 - RalfJung:offset-by-zero, r=oli-obk,scottmcm
Auto merge of #117329 - RalfJung:offset-by-zero, r=oli-obk,scottmcm
Auto merge of #117329 - RalfJung:offset-by-zero, r=oli-obk,scottmcm
Auto merge of #117329 - RalfJung:offset-by-zero, r=oli-obk,scottmcm