From: antispam@fricas.org   
      
   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.   
      
   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.   
      
   _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.   
      
   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?   
      
   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...   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)