From: Alice Ryhl <alice@ryhl.io>
To: Benno Lossin <benno.lossin@proton.me>
Cc: alex.gaynor@gmail.com, bjorn3_gh@protonmail.com,
boqun.feng@gmail.com, gary@garyguo.net,
linux-kernel@vger.kernel.org, nmi@metaspace.dk, ojeda@kernel.org,
rust-for-linux@vger.kernel.org, wedsonaf@gmail.com,
Alice Ryhl <aliceryhl@google.com>
Subject: Re: [PATCH v2 09/12] rust: init: implement Zeroable for Opaque<T>
Date: Sat, 29 Jul 2023 10:14:17 +0200 [thread overview]
Message-ID: <d106217b-b92a-56db-0c48-7ae3d1c4ee10@ryhl.io> (raw)
In-Reply-To: <18653bf6-c177-ab14-d026-2d2b5c2bbac3@proton.me>
I suggested it because it seemed less fragile.
That said, after seeing what #[derive(Eq)] expands to, I'm not so sure.
I'd probably investigate why the Eq macro has to expand to what it does.
On 7/29/23 06:11, Benno Lossin wrote:
> On 25.07.23 13:57, Alice Ryhl wrote:
>> Benno Lossin <benno.lossin@proton.me> writes:
>>> On 20.07.23 15:34, Alice Ryhl wrote:
>>>> Benno Lossin <benno.lossin@proton.me> writes:
>>>>> Since `Opaque<T>` contains a `MaybeUninit<T>`, all bytes zero is a valid
>>>>> bit pattern for that type.
>>>>>
>>>>> Signed-off-by: Benno Lossin <benno.lossin@proton.me>
>>>>> ---
>>>>> ///
>>>>> /// This is meant to be used with FFI objects that are never interpreted by Rust code.
>>>>> #[repr(transparent)]
>>>>> +#[derive(Zeroable)]
>>>>> pub struct Opaque<T> {
>>>>> value: UnsafeCell<MaybeUninit<T>>,
>>>>> _pin: PhantomPinned,
>>>>> }
>>>>
>>>> Does this actually work? I don't think we implement Zeroable for
>>>> UnsafeCell.
>>>
>>> Good catch, this does compile, but only because the current
>>> implementation of the derive expands to (modulo correct paths):
>>> ```
>>> impl<T> Zeroable for Opaque<T>
>>> where
>>> UnsafeCell<MaybeUninit<T>>: Zeroable,
>>> PhantomPinned: Zeroable,
>>> {}
>>> ```
>>> This implementation is of course useless, since `UnsafeCell` is never
>>> `Zeroable` at the moment. We could of course implement that and then this
>>> should work, but the question is if this is actually the desired output in
>>> general. I thought before that this would be a good idea, but I forgot that
>>> if the bounds are never satisfied it would silently compile.
>>>
>>> Do you think that we should have this expanded output instead?
>>> ```
>>> impl<T: Zeroable> Zeroable for Foo<T> {}
>>> const _: () = {
>>> fn assert_zeroable<T: Zeroable>() {}
>>> fn ensure_zeroable<T: Zeroable>() {
>>> assert_zeroable::<Field1>();
>>> assert_zeroable::<Field2>();
>>> }
>>> };
>>> ```
>>> If the input was
>>> ```
>>> #[derive(Zeroable)]
>>> struct Foo<T> {
>>> field1: Field1,
>>> field2: Field2,
>>> }
>>> ```
>>
>> Yeah. The way that these macros usually expand is by adding `where T:
>> Zeroable` to the impl for each generic parameter, and failing
>> compilation if that is not enough to ensure that all of the fields are
>> `Zeroable`.
>>
>> You might want to consider this expansion instead:
>> ```
>> impl<T: Zeroable> Zeroable for Foo<T> {}
>> const _: () = {
>> fn assert_zeroable<T: Zeroable>(arg: &T) {}
>> fn ensure_zeroable<T: Zeroable>(arg: &Foo<T>) {
>> assert_zeroable(&arg.field1);
>> assert_zeroable(&arg.field2);
>> }
>> };
>> ```
>
> Is there a specific reason you think that I should us references here
> instead of the expansion from above (where I just use the types and
> not the fields themselves)?
>
next prev parent reply other threads:[~2023-07-29 8:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 14:20 [PATCH v2 00/12] Quality of life improvements for pin-init Benno Lossin
2023-07-19 14:20 ` [PATCH v2 01/12] rust: init: consolidate init macros Benno Lossin
2023-07-19 18:37 ` Martin Rodriguez Reboredo
2023-07-20 13:09 ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 02/12] rust: add derive macro for `Zeroable` Benno Lossin
2023-07-19 18:42 ` Martin Rodriguez Reboredo
2023-07-20 13:13 ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 03/12] rust: init: make guards in the init macros hygienic Benno Lossin
2023-07-19 19:04 ` Martin Rodriguez Reboredo
2023-07-20 13:16 ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 04/12] rust: init: wrap type checking struct initializers in a closure Benno Lossin
2023-07-19 19:05 ` Martin Rodriguez Reboredo
2023-07-20 13:17 ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 05/12] rust: init: make initializer values inaccessible after initializing Benno Lossin
2023-07-19 19:07 ` Martin Rodriguez Reboredo
2023-07-20 13:19 ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 06/12] rust: init: add `..Zeroable::zeroed()` syntax for zeroing all missing fields Benno Lossin
2023-07-20 13:25 ` Alice Ryhl
2023-07-20 13:51 ` Martin Rodriguez Reboredo
2023-07-19 14:20 ` [PATCH v2 07/12] rust: init: Add functions to create array initializers Benno Lossin
2023-07-20 13:28 ` Alice Ryhl
2023-07-20 13:59 ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 08/12] rust: init: add support for arbitrary paths in init macros Benno Lossin
2023-07-20 13:30 ` Alice Ryhl
2023-07-20 14:02 ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 09/12] rust: init: implement Zeroable for Opaque<T> Benno Lossin
2023-07-20 13:34 ` Alice Ryhl
2023-07-24 14:16 ` Benno Lossin
2023-07-25 11:57 ` Alice Ryhl
2023-07-29 4:11 ` Benno Lossin
2023-07-29 8:14 ` Alice Ryhl [this message]
2023-07-20 14:03 ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 10/12] rust: init: make `PinInit<T, E>` a supertrait of `Init<T, E>` Benno Lossin
2023-07-20 13:36 ` Alice Ryhl
2023-07-20 14:07 ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 11/12] rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>` Benno Lossin
2023-07-21 0:23 ` Martin Rodriguez Reboredo
2023-07-24 14:08 ` Benno Lossin
2023-07-24 16:07 ` Martin Rodriguez Reboredo
2023-07-24 21:55 ` Benno Lossin
2023-07-19 14:21 ` [PATCH v2 12/12] rust: init: update expanded macro explanation Benno Lossin
2023-07-21 0:24 ` Martin Rodriguez Reboredo
2023-07-19 15:23 ` [PATCH v2 00/12] Quality of life improvements for pin-init Benno Lossin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d106217b-b92a-56db-0c48-7ae3d1c4ee10@ryhl.io \
--to=alice@ryhl.io \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nmi@metaspace.dk \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).