Undefined behavior in `split_at_unchecked`

[Lysxia]

split_at_unchecked calls ptr.add(mid) which may be UB if mid is the length of the slice. Making it ptr.wrapping_add(mid) or changing the precondition to mid < len would fix this.

rust/library/core/src/slice/mod.rs

Lines 2069 to 2079 in e7f4317

	let len = self.len();
	let ptr = self.as_ptr();
	assert_unsafe_precondition!(
	check_library_ub,
	"slice::split_at_unchecked requires the index to be within the slice",
	(mid: usize = mid, len: usize = len) => mid <= len,
	);
	// SAFETY: Caller has to check that `0 <= mid <= self.len()`
	unsafe { (from_raw_parts(ptr, mid), from_raw_parts(ptr.add(mid), unchecked_sub(len, mid))) }

[hanna-kruppe]

Offsetting a pointer so that it points at the address right after the end of the allocation is not UB (only offsetting it further is UB). This is covered by the documentation of add and related methods. While the general phrasing of the safety conditions could be interpreted differently, this case is explicitly clarified:

This implies, for instance, that vec.as_ptr().add(vec.len()) (for vec: Vec<T>) is always safe.

Also note that if this wasn’t allowed, tons of other unsafe code in the standard library and elsewhere would also be unsound, not just split_at variants.

[Lysxia]

I see, my bad. I was fixated on the phrasing of "the result must be in bounds of that allocated object", which I misinterpreted.