From: bc@freeuk.com   
      
   On 29/11/2025 20:24, Waldek Hebisch wrote:   
   > bart  wrote:   
   >> On 24/11/2025 20:26, David Brown wrote:   
   >>> On 24/11/2025 19:35, bart wrote:   
   >>   
   >>>> But now there is this huge leap, not only to 128/256/512/1024 bits,   
   >>>> but to conceivably millions, plus the ability to specify any weird   
   >>>> type you like, like 182 bits (eg. somebody makes a typo for   
   >>>> _BitInt(128), but they silently get a viable type that happens to be a   
   >>>> little less efficient!).   
   >>>>   
   >>>   
   >>> And this huge leap also lets you have 128-bit, 256-bit, 512-bit, etc.,   
   >>   
   >> 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?   
   >>   
   >> 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.   
   >>   
   >> 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.   
   >   
   > First, _BitInt(821) (and _BitInt(1187)) are really unimportant.  You   
   > simple get them as a byproduct of general rules.   
      
   That they are allowed is the problem. People use them and expect the   
   compiler to waste its time generating bit-precise code.   
      
   You can have general _BitInt(N) syntax and have constraints on the   
   values of N, not just an upper limit.   
      
   >   
   > Second, C has standard process and each proposal must go trough   
   > this process.  It is much easier to standarize one simple general   
   > frature (like _BitInt) than a bunch of separate proposals.   
   > Also, note that 64 bits is maximum guaranteed by the standard.   
   > If stanard mandated presence of say 'int128_t' that could cause   
   > opposiotion from some influential parties (like a rich company   
   > in north-west USA).  Optional 'int128_t' and 'uint128_t' adds little   
   > value.   
   >   
   > '_BitInt' is a simple interface, for example 'intnnn_t' for   
   > some 'nnn' would add multiple slots in compiler symbol table   
   > or need multiple entries in header files.  '_BitInt' is a single   
   > identifier.   
      
   I think that's how it works in Zig; i1234 is a valid integer type. It   
   can be done without defining all such type names up to maximum N.   
      
   However, I would have suggested a syntax like int(N), but I suspect it   
   clashes with something in C.   
      
      
   > _BitInt(8) makes a lot of sense for 8-bit processors.  The   
   > requirement for number of bits not divisible by 8 came from   
   > requiremnt of portablity to FPGA, where hardware may use   
   > odd width.   
      
   Wouldn't 'char' have a different width there anyway? Or can it be even   
   odder where char is 7 bits and int is 19?   
      
      
   > Even if you limit attention to mainstream hardware, 32-bit   
   > machines are still popular enough so that C must support   
   > them.  So specifying size as multiple of 64 bits would   
   > be unacceptable.  Specifying size as multiple of 32 bits   
   > would be unnatural too.  You may think that specifying   
   > size in bytes is natural, but clearly for efficiency   
   > implementation my wish to round up size.  So, why not   
   > specify size with maximal possible resolution, that is   
   > in bits?   
      
   But it means the possibility of silly or misguided sizes, or even   
   unintended ones where someone makes a typo in N and the compiler says   
   nothing because anything goes.   
      
   To me it makes sense to have N doubling, at least until some limit, then   
   increasing by word size. Below 64 bits, non-power-of-two sizes don't   
   seem that meaningful to me outside of special contexts like the members   
   of a struct, and there, there are other means to do that.   
      
      
   > BTW: you complained that C has many identifiers naming   
   > integer types.  Now C has uniform way to form names of   
   > integer types that covers most needs for fixed size   
   > integer types (sometimes you may wish promotion to   
   > integer, so 'int8_t', 'int16_t' and possibly 'int32_t'   
   > and usigned variants still may be preferable).  So now   
   > you complian that this scheme is too flexible and   
   > C should use separate names...   
      
   It's like that XCD cartoon where 14 standards end up as 15.   
      
   Apparently _BitInt(8) is incompatible with int8_t.   
      
   Yes, C type denotations were a mess, and this doesn't help.   
      
   Also, some emphasis has been put in this thread about odd and/or large   
   BitInt sizes not necessarily being a single numeric value. Yet _BitInt   
   is signed, and you have to do 'unsigned _BitInt' to get the kind of type   
   that may represent non-numeric data.   
      
   (In my PL designs, a type with 'int' in it, or of the form 'iN', is a   
   always a signed integer.   
      
   Anything else, say with 'word byte bit long', or of the form 'uN', is   
   unsigned or non-numeric.   
      
   I've also played with using N, as either a byte or bit count:   
      
      int*4       i32   
      int:32      i32   
      byte*4      u32   
      byte:32     u32   
      
   While any N could be typed, only supported sizes were accepted. But this   
   was only intended up to word or double-word size. Now I support only the   
   forms in that right column, plus 'int word byte' which are 'i64 u64 u8'.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)