Re: [PATCH v3 5/5] rust: Add KUNIT tests for bitfield

[Joel Fernandes <joelagnelf@nvidia.com>]

On Tue, Sep 16, 2025 at 05:59:18AM -0400, Joel Fernandes wrote:
[...]
> > > > The same question for the setters. What would happen for this:
> > > > 
> > > >     let bf = bf::default()
> > > >              .set_state(0xf)
> > > >              .set_ready(true);
> > > > 
> > > > I think that after the first out-of-boundary in set_state(), you
> > > > should abort the call chain, make sure you're not touching memory
> > > > in set_ready() and returning some type of error.
> > > 
> > > Here, on out of boundary, we just ignore the extra bits passed to
> > > set_state. I think it would be odd if we errored out honestly. We are
> > > using 'as u8' in the struct so we would accept any u8 as input, but
> > > then if we complained that extra bits were sent, that would be odd.
> > 
> > That really depends on your purpose. If your end goal is the safest API
> > in the world, and you're ready to sacrifice some performance (which is
> > exactly opposite to the C case), then you'd return to your user with a
> > simple question: are you sure you can fit this 8-bit number into a 3-bit
> > storage?   
> 
> I think personally I am OK with rejecting requests about this, so we can
> agree on this.

It is not possible to reject values passed to set, because it returns Self
and follows the builder-pattern, to do this we will need to return Result,
and have the caller unwrap it, and have to rename it to try_set().

Instead of that, I would just extract the bits from the value the user passed
and ignore the rest (example if 0xff is passed for a 4-bit bitfield, then the
field is 0xf.)

Alex what do you think, should set_ be fallible?

thanks,

 - Joel