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/[email protected]/ > [2] https://lore.kernel.org/all/[email protected]/
