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

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

> On May 13, 2026, at 05:00, Robert Elz via gnats <gnats-admin%netbsd.org@localhost> wrote:
> 
> The following reply was made to PR lib/60249; it has been noted by GNATS.
> 
> 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
> 
>     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>
> 
>   | It does seem strange that we've carried this (signed) int/(unsigned) size_t
>   | macro... at all,
> 
> 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).
> 
> But:
> 
>   | let alone for so long
> 
> 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).
> 
> So, regardless of what might be, in at least my, and clearly your, opinion,

Oops - I hope I didn’t sound too rant-y. I expected the response you gave, and understand all the rationale, but feel compelled to poke the design. 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.
> 
>   | Thanks again though for addressing the original PR - the macros
>   | are better than they were.
> 
> OK, thanks, I will close the PR.
> 
> kre
>