From: david.brown@hesbynett.no   
      
   On 14/01/2026 23:53, Keith Thompson wrote:   
   > David Brown  writes:   
   > [...]   
   >> Would it be allowed (in the sense of being possible in a hypothetical   
   >> but fully conforming implementation) to have "unsigned long" be   
   >> 32-bit, without padding, while "unsigned int" is 64-bit wide with 32   
   >> value bits and 32 padding bits?  A cpu might be able to handle 64-bit   
   >> lumps faster than 32-bit lumps and choose such a setup to make   
   >> "unsigned int" as fast as it can.  (uint32_t in this case would be an   
   >> alias for "unsigned long", as it can't have padding bits.)   
   >   
   > The *width* of an integer type is the number of value bits plus the sign   
   > bit, if any, so "64-bit wide" is an incorrect description.   
   >   
      
   Sorry, my terminology was imprecise.  I had meant 32 bits wide (value   
   bits) but a size of 64 bits (including padding).   
      
   > What would be possible is:   
   >   
   > - CHAR_BIT * sizeof (unsigned int) == 64   
   > - UINT_WIDTH == 32 (32 padding bits)   
   > - CHAR_BIT * sizeof (unsigned long) == 32   
   > - ULONG_WIDTH == 32 (no padding bits)   
   >   
   > The *_WIDTH macros are new in C23.   
   >   
   > [...]   
   >   
      
   So you agree that it would be possible?  (I'm sure we agree that it is   
   very unlikely in practice!)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)