On Mar 19, 2024, at 3:34 AM, Benno Lossin benno.lossin@proton.me wrote:
On 3/19/24 06:28, Laine Taffin Altman wrote:
On Mar 18, 2024, at 9:39 PM, Boqun Feng boqun.feng@gmail.com wrote:
On Mon, Mar 18, 2024 at 08:17:07PM -0700, Laine Taffin Altman wrote:
On Mar 18, 2024, at 10:25 AM, Boqun Feng boqun.feng@gmail.com wrote:
On Wed, Mar 13, 2024 at 11:09:37PM +0000, Benno Lossin wrote:
From: Laine Taffin Altman alexanderaltman@me.com
It is not enough for a type to be a ZST to guarantee that zeroed memory is a valid value for it; it must also be inhabited. Creating a value of an uninhabited type, ZST or no, is immediate UB. Thus remove the implementation of `Zeroable` for `Infallible`, since that type is not inhabited.
Cc: stable@vger.kernel.org Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 Signed-off-by: Laine Taffin Altman alexanderaltman@me.com Signed-off-by: Benno Lossin benno.lossin@proton.me
I think either in the commit log or in the code comment, there better be a link or explanation on "(un)inhabited type". The rest looks good to me.
Would the following be okay for that purpose?
A type is inhabited if at least one valid value of that type exists; a type is uninhabited if no valid values of that type exist. The terms "inhabited" and "uninhabited" in this sense originate in type theory, a branch of mathematics.
In Rust, producing an invalid value of any type is immediate undefined behavior (UB); this includes via zeroing memory. Therefore, since an uninhabited type has no valid values, producing any values at all for it is UB.
The Rust standard library type `core::convert::Infallible` is uninhabited, by virtue of having been declared as an enum with no cases, which always produces uninhabited types in Rust. Thus, remove the implementation of `Zeroable` for `Infallible`, thereby avoiding the UB.
Yeah, this works for me. Thanks!
Great! Should it be re-sent or can the new wording be incorporated upon merge?
I can re-send it for you again, or do you want to send it yourself? I think it is also a good idea to add a link to [1] in the code, since the above explanation is rather long and fits better in the commit message.
I’ll try and do it myself; thank you for sending the first round for me and illustrating procedures! What Reviewed-By’s/Signed-Off-By's should I retain?
Thanks, Laine
-- Cheers, Benno