On Fri Oct 9, 2026 at 12:47 AM JST, Yury Norov wrote: > 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.
As it turns out we would never perform a zero-sized malloc, even for a zero-sized bitmap. `IdPool` is backed by a `BitmapVec`, which up to `usize::BITS` uses an inline member as backing storage. So we would never call `bitmap_zalloc` with a value of 0, making the safety concern moot. > > 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. I don't know of an in-kernel example, but please look at the `bitmap_vec_new` test which has been here since the API was initially merged last year: the first thing it does is create a zero-sized bitmap. It is also easy to imagine a user starting with an empty pool and growing it on-demand. Having the ability to create a zero-sized pool is convenient to avoid special-casing user code, and in this case I'd say expected, just like you can create a zero-sized vector. Again a size of zero does not trigger anything that a larger capacity cannot trigger, so I don't see a reason to forbid it. > >> 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. Right now out-of-bound accesses are allowed if `CONFIG_RUST_BITMAP_HARDENED` is not set. The Kconfig documentation for that option even says "if unsure, say N", which suggests that not panicking (and thus the behavior I described above for `next_zero_bit`) is the default. If out-of-bound accesses should panic, then the Kconfig does not reflect that. > > 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. With hardening off, every function already behaves in that way, and existing user code is already written to not trigger that condition anyway (because of the possibility of a panic), so that would be a pretty innocuous change.
