Re: [PATCH v3 1/2] rust: add projection infrastructure

["Benno Lossin" <lossin@kernel.org>]

On Mon Mar 2, 2026 at 11:19 PM CET, Gary Guo wrote:
> On Mon Mar 2, 2026 at 10:01 PM GMT, Benno Lossin wrote:
>> On Mon Mar 2, 2026 at 9:14 PM CET, Gary Guo wrote:
>>> On Mon Mar 2, 2026 at 6:49 PM GMT, Benno Lossin wrote:
>>>> On Mon Mar 2, 2026 at 3:49 PM CET, Gary Guo wrote:
>>>>> On Mon Mar 2, 2026 at 2:38 PM GMT, Benno Lossin wrote:
>>>>>> On Mon Mar 2, 2026 at 2:02 PM CET, Gary Guo wrote:
>>>>>>> +/// A helper trait to perform index projection.
>>>>>>> +///
>>>>>>> +/// This is similar to `core::slice::SliceIndex`, but operate on raw pointers safely and fallibly.
>>>>>>> +///
>>>>>>> +/// # Safety
>>>>>>> +///
>>>>>>> +/// `get` must return a pointer in bounds of the provided pointer.
>>>>>>
>>>>>> This only makes sense when the provided pointer already points at an
>>>>>> allocation. But since the functions of this trait aren't `unsafe`, it
>>>>>> must be sound to pass `ptr::null` to them.
>>>>>
>>>>> The "in bounds" here is the conceptual bounds of the pointer. So, for a pointer
>>>>> with size `x`, the address of the returned pointer lies between `ptr .. ptr +
>>>>> x`.
>>>>
>>>> Okay, I haven't really seen that as a concept. Also, what is the size of
>>>> an invalid pointer?
>>>
>>> It's `size_of::<T>()` for sized types, and `size_of::<T>() * slice.len()` for a
>>> raw slice pointer.
>>
>> And for `dyn Trait`?
>>
>> Do you have a link to somewhere?
>
> For `dyn Trait` it would be the size in the vtable, which is always available as
> vtable metadata on a raw pointer is required to be valid anyway (this is
> something that lang team has already decided so that trait upcasting could work
> for raw pointers).

I really would like to see some docs of that, I didn't find anything in
the reference, official docs, or nomicon. The reference does say [1]
that:

    `dyn Trait` metadata must be a pointer to a compiler-generated
    vtable for Trait. (For raw pointers, this requirement remains a
    subject of some debate.)

Do you know where it was decided? I did find this [2] UCG issue that
covers it, but that doesn't seem like the decision, just the discussion.

[1]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.validity.wide
[2]: https://github.com/rust-lang/unsafe-code-guidelines/issues/516

> I am basically just having `size_of_val_raw` in mind when writing this. So the
> current `KnownSize` comment in v4 is something that I am happy about.

Well size_of_val_raw is `unsafe` and only valid to call in certain
conditions. It asks in the case of slices that the length is an
initialized integer and that the entire value must fit into `isize`.
This to me just further indicates that `*mut T` has safety
requirements to obtaining the size of an arbitrary pointer.

In the special cases of `T: Sized` and `T == [U]`, we have safe ways of
getting their size.

Cheers,
Benno