Re: [PATCH v9 8/9] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN

[Yury Norov <ynorov@nvidia.com>]

On Thu, Oct 01, 2026 at 03:20:40PM +0900, Alexandre Courbot wrote:
> On Wed Sep 30, 2026 at 2:05 PM JST, Yury Norov wrote:

...

> > Allocating a pool with 0-bit capacity is wrong. Please don't put it
> > in the examples. I recall I pointed that this object would panic the
> > kernel if, for example, you call pool.next_zero_bit(0) immediately
> > after this. Sorry, but NAK.
> >
> > This .with_capacity() should take num_ids: NonZero, after all...
> 
> This panic is not specific to the size zero, any size triggers the same
> behavior when accessed out of bounds.

In C, malloc(0) is implementation defined behavior, i.e. it can return
a pointer valid for free(), or NULL (which is also valid for free).

This is a very old legacy coming from K&R implementation, then rejected
in C89, and later this all became an impl-def, mostly for compatibility
reasons. See 7.20.3 in

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n937.pdf

Rust adopted C bitmaps, thus creating 0-bit bitmap may go through, and
hit that questionable behavior. You add this example without any
discussion about all that possible complications, and with no
protection for users.

Interestingly, you're doing it for the reason that has been considered
a bad practice for over 30 years ago - malloc(0) with the immediate
realloc(). See the above link for details.

To me it looks like pulling legacy with a potential of undefined behavior
into Rust.

Bitmaps is a way more simple case than the generic malloc(). There's the
only user of bitmaps - the Linux kernel, so we know exactly all users and
their user patterns. I'm not aware of any in-tree user allocating 0-length
bitmap for whatever reason, and such a coding style is highly unwelcome
nowadays (30+ years).

When it comes to rust, things are even simpler. Rust has much stricter
memory policy - no undefined behavior, no implementation-defined behavior
is allowed, no 50-years old legacy has to be considered.

Rust community decided to take the existing in-kernel implementation of
bitmaps written in C, for a reason. But with that it pulls all undefined
and poorly defined behavior associate to C language. We did quite well
spotting such places and fencing them with safety checks.

The 0-length bitmaps is just another case that should be resolved.

If you still think that you need 0-length bitmaps in Rust, can you please
give the clear and thorough explanation why rust needs those 0-length
bitmaps. Are there any in-kernel examples? Any language concepts requiring
it? If not, it's still a NAK.

> A size of zero has nothing special
> in that respect, so why make an exception and forbid it? We had this
> discussion some time ago [1][2], and I'd recommend instead making e.g.
> `next_zero_bit` return `None` on out-of-bounds accesses, which is
> semantically correct.

No. out-of-bound access should panic because every caller of bitmap
API knows the length of that bitmap.

But if you make that 0-length bitmap a valid case, we need to revisit
every function and make sure it returns ENOENT or something instead of
panicking. That, again, must be very well explained and justified, and
all this has to be done before adding 0-length bitmap support in code
and examples.

Thanks,
Yury

> [1] https://lore.kernel.org/all/ao2GHqop_Z_9bsyl@google.com/
> [2] https://lore.kernel.org/all/ao2U1jNaT7waibJW@google.com/