From: bc@freeuk.com   
      
   On 25/11/2025 20:25, David Brown wrote:   
   > On 24/11/2025 23:27, bart wrote:   
      
   >> On interesting use-case for literals was short-strings; 128 bits   
   >> allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. I   
   >> think C is still stuck at one, or 4 if you're lucky.)   
   >>   
   >   
   > I have no idea or opinion on why /you/ might want 128-bit or larger   
   > integer types.  I believe there is very little use for "normal" numbers   
   > - things you might want to write as literals, calculate with, and read   
   > or write - that won't fit perfectly well within 64 bit types, and would   
   > not be better served by arbitrary sized integers.   
      
      
   >  Arbitrary sized   
   > integers are a very different kettle of fish from large fixed-size   
   > integers, and are not something that would fit in the C language - they   
   > need a library.   
      
   Really? I wouldn't have thought there was any appreciable difference   
   between the code for multiplying two 100,000-bit BitInts, and that for   
   multiplying two abitrary-precision ints that happen to be 100,000 bits.   
      
   Maybe the latter is autoranging, and might give a 200,000-bit result.   
      
   Presumably the former doesn't use inline code, so it would be surprising   
   if each distinct size of BitInt had dedicated sets of routines for this.   
   So it sounds like they have to use a generic library anyway.   
      
   And sure enough, gcc-generated code contains stuff like this:   
      
   	mov	r8, rcx   
   	mov	edx, 50000       # (BitInt(50000)   
   	mov	rcx, rax   
   	call	__mulbitint3   
      
   So, BitInts are different in that they /don't/ need a library?   
      
   >   
   > I can tell you why /I/ might find larger integer types useful.  They   
   > include :   
   >   
   > * 128-bit for IPv6 address.  These use a variety of styles for input and   
   > display, and thus would use specialised routines, not simple literals or   
   > printf-style IO.   
      
   So, a better fit for a struct then? Here I'm curious as to what   
   BitInt(128) brings to the table.   
      
      
   > * Big units for passing data around with larger memory transfers, using   
   > SIMD registers.  IO is irrelevant here.   
      
   Structs and arrays again spring to mind if you just want an anonymous   
   data block. (I wonder why it has to be bit-precise for byte-addressed   
   memory?)   
      
      
   > * Cryptography.  IO is irrelevant here.  But a variety of sizes are   
   > useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048, 3072,   
   > 4096, 7680, 8096 bits.  There may be more common sizes - I'm just   
   > thinking of DES, 3DES, AES, SHA, ECC and RSA.   
      
   And I'm again curious as to what /non-numeric/ use a 200,000-bit BitInt   
   might be put to, that is not better served by an array or struct.   
      
   Maybe bit-sets? But there are no special features for accessing   
   individual bits.   
      
   That BigInt() defaults to a signed integer (twos complement?), even for   
   very large sizes suggests that /numeric/ applications are a primary use.   
      
   >   
   >   
   > Smaller sizes can be useful for holding RGB pixel values, audio data, etc.   
      
   Except that these are probably rounded up, to the next multiple of two.   
   So the benefit is minimal; it do something with those padding bits.   
      
   >> And 821 bits. This is what I don't get. Why is THAT so important?   
   >>   
   >> Why couldn't 128/256/etc have been added first, and then those funny   
   >> ones if the demand was still there?   
   >   
   > The folks behind the proposal provided both.  The fact that you can   
   > write _BitInt(821) does not in any way hinder use of _BitInt(256).  I   
   > really don't get your problem here.   
      
   You've heard of 'code smell'? Well, this is the same, but for features.   
      
   I've been doing this stuff long enough to recognise when a feature is   
   over-elaborate, over-specified and over-flexible. You need to know the   
   minimum you can get away with, not the maximum!   
      
   Let me guess, some committee members have been looking too long at how   
   C++ does things? That language is utterly incapable of creating anything   
   small and simple.   
      
      
   >>   
   >> If the proposal had instead been simply to extend the 'u8 u16 u32 u64'   
   >> set of types by a few more entries on the right, say 'u128 u256 u512',   
   >> would anyone have been clamouring for types like 'u1187'? I doubt it.   
   >   
   > /You/ might not have wanted them, but other people would.   
      
      
      
   OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit   
   signed integer. It might only have two values of 0 and -1; doesn't   
   nobody want that particular combination?   
      
      
      
      
   >>   
   >> For sub-64-bit types on conventional hardware, I simply can't see the   
   >> point, not if they are rounded up anyway. Either have a full range-   
   >> based types like Ada, or not at all.   
   >>   
   >   
   > Fortunately for the C world, you are not on the C committee - it doesn't   
   > matter if you can't see beyond the end of your nose.   
      
   Maybe unfortunately. C used to be a fairly simple language with a lot of   
   baggage; now it's a much heftier one with a lot of baggage!   
      
   At least, I've been able to add to my collection of C types that   
   represent an 8-bit byte:   
      
       signed char   
       unsigned char   
       int8_t   
       uint8_t   
       _BitInt(8)   
       unsigned _BitInt(8)   
      
   The last two are apparently incompatible with the char versions.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)