`AbstractPtr<'_, _, [T], _>::index()` and `split_at()` fail when range is `self.len()..self.len()`

[lgs-confiware]

Indexing into an AbstractPtr<'_, _, [T], _> with a range a..b where a is equal to the pointer's length panics:

fn test_index<'a, M, T, A: Access>(ptr: AbstractPtr<'a, M, [T], A>) {
    // Works fine
    let ptr2 = ptr.index(0..ptr.len());
    assert_eq!(ptr, ptr2);

    // Panics: "index out of bounds: the len is 9 but the index is 9"
    // ptr.index(ptr.len()..ptr.len());

    // Works fine
    let len_zero_ptr = ptr.index(0..0);

    // Panics: "index out of bounds: the len is 0 but the index is 0"
    // len_zero_ptr.index(0..0);
}

For reference, indexing like that does work on regular slices:

let slice = &(vec![1, 2, 3])[3..3];
assert_eq!(slice, &[]);

The same happens with AbstractPtr::split_at, where if mid == self.len() it will panic for the same reason:

fn test_split_at<'a, M, T, A: Access>(ptr: AbstractPtr<'a, M, [T], A>) {
    // Works fine
    ptr.split_at(4);
    ptr.split_at(0);

    // Panics: "index out of bounds: the len is 9 but the index is 9"
    // ptr.split_at(ptr.len());

    let len_zero_ptr = ptr.index(0..0);
    // Panics: "index out of bounds: the len is 0 but the index is 0"
    // len_zero_ptr.split_at(0);
}

The comments inside split_at seem to hint that this case should indeed work:

rust-sel4/crates/sel4-abstract-ptr/src/abstract_ptr/slice_operations.rs

Line 127 in 285045d

// SAFETY: Caller has to check that `0 <= mid <= self.len()`