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

["B Harder via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/60249; it has been noted by GNATS.

From: B Harder <brad.harder%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, kre%netbsd.org@localhost
Subject: Re: lib/60249 (bitstring bit_ffc(), bit_ffs() type conflicts)
Date: Tue, 12 May 2026 23:44:00 -0700

 =EF=BB=BF
 
 
 > 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  signatu=
 re.
 
 It does seem strange that we've carried this (signed) int/(unsigned) size_t m=
 acro... at all, let alone for so long - can anybody explain why we don't use=
  (e.g.) ints everywhere here, testing >=3D0 where appropriate, and match the=
  size of the possible answer with the size of the search set? Is there some a=
 rch 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 a=
 n absurd enough sized bitfield?), but limit the possible answer to an int - w=
 hile the casts appease the compiler, at the limits (someone expecting the in=
 dex of the INT_MAX+1 of a sufficiently-sized size_t bitfield), we'll be retu=
 rning incorrect answers, no?
 
 Thanks again though for addressing the original PR - the macros are better t=
 han they were.
 
 -bch
 
 > =EF=BB=BFSynopsis: bitstring bit_ffc(), bit_ffs() type conflicts
 >=20
 > 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.