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

["Gary Guo" <gary@garyguo.net>]

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 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.

>
>> The projection semantics is same regardless whether it's valid or not. The I/O
>> projection work will rely on this, as many I/O impls will act on pointers that
>> are not "valid" in Rust sense because they refer to a different address space.
>> But they're still legit pointers with proper meaning.
>
> I like the solution with `KnownSize`. The previous safety requirement
> was nebulous IMO.

Best,
Gary