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

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

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

From: bch <brad.harder%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/60249 (bitstring bit_ffc(), bit_ffs() type conflicts)
Date: Thu, 14 May 2026 13:46:04 -0700

 > On May 13, 2026, at 05:00, Robert Elz via gnats <gnats-admin%netbsd.org@localhost> w=
 rote:
 >=20
 > =EF=BB=BFThe following reply was made to PR lib/60249; it has been noted b=
 y GNATS.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: lib/60249 (bitstring bit_ffc(), bit_ffs() type conflicts)
 > Date: Wed, 13 May 2026 18:58:05 +0700
 >=20
 >     Date:        Tue, 12 May 2026 23:44:00 -0700
 >     From:        B Harder <brad.harder%gmail.com@localhost>
 >     Message-ID:  <ABBA54F6-E19D-4CCE-A279-EB6D05CBC474%gmail.com@localhost>
 >=20
 >   | It does seem strange that we've carried this (signed) int/(unsigned) s=
 ize_t
 >   | macro... at all,
 >=20
 > In general, I agree, and if I were designing it now, probably would not
 > use size_t (though I believe others here believe that size_t types should
 > be used to represent the size of anything, so not all would agree).
 >=20
 > But:
 >=20
 >   | let alone for so long
 >=20
 > after all this time, it is not going to change now - other code might be
 > expecting to be able to pass size_t there, after all, that is what the
 > doc states, and changing things without any particularly good reason now
 > would be an issue - macros can't even be versioned quite the same way
 > functions can when we want to change their ABI (not that they have the
 > same issues either).
 >=20
 > So, regardless of what might be, in at least my, and clearly your, opinion=
 ,
 
 Oops - I hope I didn=E2=80=99t sound too rant-y. I expected the response you=
  gave, and understand all the rationale, but feel compelled to poke the desi=
 gn. Thanks again for your help and response here.
 
 Happy computing,
 -bch
 
 
 
 
 > a better design, we won't be altering what we have in any way that affects=
 
 > the defined interface.
 >=20
 >   | Thanks again though for addressing the original PR - the macros
 >   | are better than they were.
 >=20
 > OK, thanks, I will close the PR.
 >=20
 > kre
 >=20