From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F359A3164AA; Tue, 3 Mar 2026 09:14:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772529271; cv=none; b=meihWsbHk8eA9xYvPFW2oEIEeJ8/II1LuuRJxBadCQVPk7l8bkJznyFh9wFXUoBsCvcIaHi3ypNhNHiXXpyti79e6cOwCyFqWcMeDoJxxD9sMu54rflPN4OpZZeUVznLEZwpN3Wx5CCVzyLgMd9qLMTwAYg6MimEdc6xwyPRI3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772529271; c=relaxed/simple; bh=Z363bKe+2Mgy9mV/lnzOhCsB8JU9lsSkvXHnYD7oKSc=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=Pol2DCkXKmrWRJ25yebT6KXujoYTBww3pf5qwD/UCViIbC4hPxWHXJXXUIZdnlVT2TxPnCBcm9E6NQBR5H0rrCOxZ71X6o9VCf8qSXm1SmNDDpdE8CnaK4+0vSU85W1OOE+poSJdzXDwByradcZ9hTfN9tYcJzpyu1PlOmrQb08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IPrvQ9uK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IPrvQ9uK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5402C116C6; Tue, 3 Mar 2026 09:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772529270; bh=Z363bKe+2Mgy9mV/lnzOhCsB8JU9lsSkvXHnYD7oKSc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IPrvQ9uKrGoHpwUbGAE/oqYfXIS56R0ybJgab5wP2YOi0jD1mNKt1pStys/OkJqfA YSvX9NkiopMiKXUcR74e0x/Cnb4D0OIvF+Y1lNqR2nR5d1oZVx3y5ee1oxUdeIWC+V sJKpqhMFUHMbyV/K4ByO4hJdUe9ulZdvw83vuXFehgy55KefWJHd7707M0xDpAhEqV /N8l1wGN+lL6kON5gAsB2qSatA8joGIwyfJt2djA9wNLXHTJsGdNUmxJWSSVObDFj5 O44Vo4mRo0FTyjIjXO7fvfSzmgjBl8z90IsCnt3NvSBf5gJ3I5YtJ0wHdp4AC3BTj1 rwkddMm2uC5BA== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 03 Mar 2026 10:14:25 +0100 Message-Id: From: "Benno Lossin" To: "Gary Guo" , "Miguel Ojeda" , "Boqun Feng" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , "Nathan Chancellor" , "Nicolas Schier" Cc: , "Aditya Rajan" , , Subject: Re: [PATCH v3 1/2] rust: add projection infrastructure X-Mailer: aerc 0.21.0 References: <20260302130223.134058-1-gary@kernel.org> <20260302130223.134058-2-gary@kernel.org> In-Reply-To: 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 r= aw 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`, i= t >>>>>> 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::()` for sized types, and `size_of::() * 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 avail= able 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 coul= d 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. S= o 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 =3D=3D [U]`, we have safe ways of getting their size. Cheers, Benno