Re: [PATCH v7 06/10] rust: id_pool: take a NonZero capacity in with_capacity

On Fri Aug 21, 2026 at 5:39 PM JST, Alexandre Courbot wrote:
> On Mon Aug 17, 2026 at 4:04 PM JST, Eliot Courtney wrote:
>> There is no good reason to allocate an IdPool with zero capacity.
>> Reflect this in IdPool::with_capacity.
>>
>> Signed-off-by: Eliot Courtney <[email protected]>
>
> I am not sure this one is justifiable; `KVec::with_capacity(0)` is
> doable, so why not here? As long as it doesn't introduce soundness
> issues I'd say this is the caller's business; a driver with a legitimate
> empty IdPool use-case would now need to special-case it.
>
> Now we do have an actual soundness issue with zero-sized IdPools, which
> is that `find_unused_id` would panic with `CONFIG_RUST_BITMAP_HARDENED`,
> but as I said on patch 5 I don't think it should anyway. Another
> potential issue is that `grow_request` would not grow anything; but that
> should be fixed there by handling the `capacity == 0` case. Actually
> that would give justification for empty IdPools to exist: just like a
> vector can start empty and grow, so can an IdPool.

I don't have a very strong opinion here but I can't really think of a
use case for a zero capacity IdPool. Unlike an empty vector, since
IdPool doesn't automatically grow (there is a notion of a fixed ID
space), the only thing you can do with a zero capacity IdPool is grow it
to non-zero. All the other operations don't do anything useful.

If such a use case exists, maybe it'd have to be something like you are
using the capacity to identify your ID space size (and the ID space size
is important otherwise you would just use IdPool::new() with the
MAX_INLINE_LEN capacity) but then the only way you can grow it is via
grow_request() which doesn't grow the ID space in caller controllable
way.

Anyway, let me know if you feel strongly about this one. FWIW, previous
to this patch series you couldn't construct a 0 capacity IdPool either.