From: bc@freeuk.com   
      
   On 01/12/2025 04:10, Waldek Hebisch wrote:   
   > bart  wrote:   
   >> On 01/12/2025 00:08, Waldek Hebisch wrote:   
   >>> bart  wrote:   
   >>>>   
   >>>> Yet what I said is pretty much true. Nobody care about BitInt until they   
   >>>> became aware of, and now it's must-have.   
   >>>   
   >>> Well, you were told many times that regulars here know deficiencies   
   >>> of C.  "Nobody care about BitInt" in the sense that before _BitInt   
   >>> people will say "this can not be expressed directly in C, you need   
   >>> such and such workaround".  People did not loudly complain   
   >>> knowing that complaints would achive nothing.  But say doing   
   >>> language comparisons they could note that C lack such a feature.   
   >>>   
   >>> There is also a psychological phenomenon: computers even in crude   
   >>> form are quite useful.  So people were willing to jump hops to   
   >>> use them.  But when better/easier approach is available people   
   >>> wery strongly resist going to old ways.  So, once w got _BitInt   
   >>> you will not be able to take it back.   
   >>   
   >>   
   >> I've been claiming that _BitInt was a poor fit for a language at the   
   >> level of C which lacks some more fundamental features.   
   >>   
   >> But I think I was wrong: the way _BitInt has been devised and presented   
   >> is actually completely in line with the haphazard way C has evolved up   
   >> to now.   
   >>   
   >> I made the mistake in this thread of thinking that people cared about   
   >> measured language design; obviously if they're using C, they don't.   
   >>   
   >>    unsigned char*       p;   
   >>    uint8_t*             q;   // only exists when stdint.h used   
   >>    unsigned _BitInt(8)* r;   
   >>    char*                s;   
   >>   
   >> p and q are probably compatible. p and r are not; q and r and not. s is   
   >> incompatible with p, q, r even if it is unsigned.   
   >   
   > Do you understand that uint8_t and _BitInt(8) are different types?   
      
   Well, apparently they aren't. It's not immediately obvious why, but as I   
   explained above, I realise this is entirely in keeping with how C works.   
      
   > And the difference is not an accident, but they have different   
   > properties (uint8_t in expressions promotes to int, _BitInt(8)   
   > is not subject to this promotion).   
      
   This is another little rule that is not obvious, and out of keeping with   
   how other types work. Yet add _BitInt(8) to _BitInt(16), and one side   
   /is/ promoted.   
      
   My example was just to highlight the plethora of type denotations that   
   exist, even for the same machine type. The rules for type-compatibility   
   and promotions (and the ugly syntax) is just icing on top.   
      
   This ungainly way to evolve a language is how C works (just look at all   
   the things wrong with how stdint.h types were handled).   
      
   The following table for example shows the rules for mixed sign   
   arithmetic: S means the result (32 or 64 bits) has signed type, and u   
   means it is unsigned:   
      
           u8  u16 u32 u64  i8  i16 i32 i64   
      
       u8   S   S   u   u    S   S   S   S   
      u16   S   S   u   u    S   S   S   S   
      u32   u   u   u   u    u   u   u   S   
      u64   u   u   u   u    u   u   u   u   
      
       i8   S   S   u   u    S   S   S   S   
      i16   S   S   u   u    S   S   S   S   
      i32   S   S   u   u    S   S   S   S   
      i64   S   S   S   u    S   S   S   S   
      
   But of course, every C programmer knows this and doesn't need such a chart!   
      
   Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) +   
   _Bitint(8)' apparently gives an unsigned result (tested using _Generic).   
      
   So another plus point for staying close to the C spirit!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)