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)