Re: [PATCH] rust: bitfield: require Zeroable storage for Zeroable impl

From: Alexandre Courbot

Date: Tue Sep 22 2026 - 10:23:25 EST


On Mon Sep 21, 2026 at 7:05 PM JST, Gary Guo wrote:
> On Mon Sep 21, 2026 at 8:18 AM BST, Alexandre Courbot wrote:
>> On Mon Sep 21, 2026 at 3:32 PM JST, Yilin Chen wrote:
>>> Hi Gary,
>>>
>>> Resending my reply for visibility on the mailing list.
>>>
>>> You are right that a bitfield with at least one field generates a use of
>>> `Bounded<$storage, ...>`, which requires the storage type to implement
>>> `Integer`. However, `bitfield!` also accepts an empty field list. In that
>>> case, no `Bounded` use is generated, so the `Integer` requirement is
>>> absent, while the macro still generates the unconditional `Zeroable`
>>> implementation.
>>>
>>> For example:
>>>
>>> use core::num::NonZeroU32;
>>> use pin_init::Zeroable;
>>>
>>> bitfield! {
>>> struct Bad(NonZeroU32) {}
>>> }
>>>
>>> fn check_bad_zeroable() {
>>> let _: Bad = <Bad as Zeroable>::zeroed();
>>> }
>>>
>>> This currently compiles.
>>
>> No it doesn't.
>>
>> error[E0277]: the trait bound `core::num::NonZero<u32>: kernel::mem::AsRepr` is not satisfied
>> 364 | / bitfield! {
>> 365 | | struct Bad(NonZeroU32) {}
>> 366 | | }
>> | |_________^ the trait `kernel::mem::AsRepr` is not implemented for `core::num::NonZero<u32>`
>
> On the other hand, it makes sense for `NonZero<u32>` to implement
> `AsRepr<Repr = u32>`. So I think we do need better defense.
>
> Given that fundamental `bitfield!` needs a plain integer type, I don't think we
> want a `Zeroable` bound, but rather just enforce it has to be integer
> primitives.
>
> Given the recent `Integer` sealing, ad a check that $storage implements
> `Integer` is probably the best check.

That, or we only derive `Zeroable` on a bitfield if its storage type
also implements `Zeroable`.

... but that possibly leaves other ways in which the invariant for
`NonZero` would not be enforced, and I don't see the point for a
bitfield to be backed by anything but a primitive type, so maybe
limiting storage to implementors of `Integer` is the right move indeed.

Yilin, do you want to send a patch for this?