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

[Gary Guo]

On Tue Mar 3, 2026 at 9:14 AM GMT, Benno Lossin wrote:
> 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.

The FCP is here: https://github.com/rust-lang/rust/issues/101336

The gist: for a fat raw pointer with `dyn Trait` metadata, the safety invariant
requires a fully valid vtable. Validity invariant is not yet decided.

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

Hmm, the `isize` fitting requirement is problematic indeed. It's broken code if
pointer projection is used with an allocation that exceeds the limit, but I want
the API to be safe, so it'll be good if the API is defined to just be wrapping
and safe (it may return values that doesn't make sense, but that'll be on the
user).

Anyhow this is moot as we're going the `KnownSize` route.

Best,
Gary

>
> Cheers,
> Benno