From: bc@freeuk.com

On 25/11/2025 02:03, Keith Thompson wrote:
> bart  writes:
>> On 24/11/2025 14:41, David Brown wrote:
>>> On 24/11/2025 13:31, bart wrote:
>>> That's all up to the implementation.
>>> You are worrying about completely negligible things here.
>>
>> Is it that negligible? That's easy to say when you're not doing the
>> implementing! However it may impact on the size and performance of
>> code.
>
> You're right, it's easy to say when I'm not doing the implementing.
> Which I'm not.
>
> The maintainers of gcc and llvm/clang have done that for me, so I don't
> have to worry about it.
>
> Are you planning to implement bit-precise integer types yourself?  I
> don't think you've said so in this thread.  If you are, you have at
> least two existing implementations you can look at for ideas.

No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits, and
played with 1/2/4 bits, but my view is that above this range, using
exact bit-sizes is the wrong way to go.

While for odd sizes up to 64 bits, bitfields are more apt than employing
the type system.

> Here's an idea.  Rather than asserting that _BitInt(1'000'000)
> is silly and obviously useless, try *asking* how it's useful.
> I personally don't know what I'd do with a million-bit integer,
> but maybe somebody out there has a valid use for it.  Meanwhile,
> its existence doesn't bother me.

Again, my view is that types like _BitInt(123456) (could they have made
it any more fiddly to type?!) is the same mistake that early Pascal made
with arrays.

It is common that an N-array of T and an M-array of T are not
compatible, but usually there are ways to deal generically with both.


> My guess is that once you've implemented integers wider than 128
> or 256 bits, million-bit integers aren't much extra effort.

I've implemented 128-bit arithmetic, and have seen some scary-looking C
code that implemented 256-bit arithmetic. Neither of those would scale
to N-bits where N can be arbitrary large /and/ might not be a multiple
of either 64 or 8.

You would need pretty much the same algorithms as used for arbitrary
precision. Those usually require N to be some multiple of 'limb' size.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)