Re: lib/60249 (bitstring bit_ffc(), bit_ffs() type conflicts)

[B Harder <brad.harder%gmail.com@localhost>]




> On May 11, 2026, at 14:34, kre%netbsd.org@localhost wrote:

Hi.

Thanks kre@ for reconciling the types, and incorporating the required header - this fixes the immediate issue, and preserves the function/macro  signature.

It does seem strange that we've carried this (signed) int/(unsigned) size_t macro... at all, let alone for so long - can anybody explain why we don't use (e.g.) ints everywhere here, testing >=0 where appropriate, and match the size of the possible answer with the size of the search set? Is there some arch where this made sense? Should it be changed going forward?  As it stands it behaves like it can take a size_t width bitmap (is not INT_MAX already an absurd enough sized bitfield?), but limit the possible answer to an int - while the casts appease the compiler, at the limits (someone expecting the index of the INT_MAX+1 of a sufficiently-sized size_t bitfield), we'll be returning incorrect answers, no?

Thanks again though for addressing the original PR - the macros are better than they were.

-bch

> Synopsis: bitstring bit_ffc(), bit_ffs() type conflicts
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: kre%NetBSD.org@localhost
> State-Changed-When: Mon, 11 May 2026 21:34:27 +0000
> State-Changed-Why:
> I believe this should be fixed in HEAD now (any daily build after
> May 11 21:16:39 UTC 2026).   Let us know if there are further problems.