linux-kernel - Re: [PATCH 1/2] rust: add BitInt integer wrapping type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQpUSw49QptgxjFz@yury>
Date: Tue, 4 Nov 2025 14:30:19 -0500
From: Yury Norov <yury.norov@...il.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Danilo Krummrich <dakr@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Jesung Yang <y.j3ms.n@...il.com>, Boqun Feng <boqun.feng@...il.com>,
	Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 1/2] rust: add BitInt integer wrapping type

On Tue, Nov 04, 2025 at 12:13:26PM +0900, Alexandre Courbot wrote:
> On Tue Nov 4, 2025 at 4:36 AM JST, Yury Norov wrote:
> > On Mon, Nov 03, 2025 at 10:42:13PM +0900, Alexandre Courbot wrote:
> >> Hi Yury,

...

>     let a = BitInt::<u8, 3>::new::<3>();
>     let b = BitInt::<u16, 10>::new::<123>() + a.cast::<u16>();
> 
>     let c = a.cast::<u32>() + u32::from(b);
> 
> Note that `b` and `c` are regular `u16` and `u32`. Arithmetic operations
> cannot guarantee that the BitInt invariant will be maintained, so the
> result needs to be converted back if that's what one wants.

What C does and what I proposed is to make BitInt a 1st class type,
just like basic integers. What you implement is really a bounded int.

Both have advantages. C-style BitInt() is a true type with all type
guarantees. And I like it more because it is a natural extension of
the existing integer scheme.

Your bounded ints are actually classical integers with some limitations.
It's not a primitive type in sense of C - it's an object. It also works
fine. You can easily extend it to arbitrary min and max limits; you can
expand it to floating types, and do whatever you can do with the objects.

        BitInt(i32, -128, 255)
        BitFloat(f32, -1, 1)

That's why you think that -1i32 fits into BitInt(i32, 4), and even
into BitInt(i8, 4), while I don't.

I don't know which would work better for bitfields. Most likely both
would work reasonably well. And if bitfield will carefully hide
internals, I hope most users will not care much.

You switched name to BitInt, but still think about it as an object,
and that brought all the confusion in my mind. Maybe switch back to
BoundedInt then to avoid this confusion? If you find it lengthy,
probably LimInt or simply Lint will be better for you.

Looking at how good rust macros work to implement bitfields, I thought
that they will be able to mimic native types just as well. But now it
seems like an arbitrary-length integer types requires support on
language side. Just like in C.

With that in mind, I think that bounded integers are a bit out of
scope of basic bit operations, and probably I'm not a right person
to maintain them neither in Rust, nor in C.

Please keep me in CC for next versions.

Thanks,
Yury