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

[Gary Guo]

On Tue Mar 3, 2026 at 11:39 AM GMT, Alice Ryhl wrote:
> On Tue, Mar 03, 2026 at 10:17:01AM +0000, Gary Guo wrote:
>> 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:
>> >> 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.
>
> It sounds like that's no different from dyn trait vtable case. Fat
> pointer must have valid metadata, even if raw pointer.

If you have a `*const dyn Trait`, then yes, it's all valid. However, the `isize`
fitting requirement means that if you have `*const TypeWithUnsizedTail<dyn
Trait>`, the fixed-sized prefix, when added together with the `dyn Trait` tail,
may exceed isize::MAX and violate the safety requirement of `size_of_val_raw`.

Best,
Gary

>
> Alice