From: already5chosen@yahoo.com   
      
   On Sun, 11 Jan 2026 16:34:28 +0100   
   David Brown  wrote:   
      
   > On 11/01/2026 14:32, Michael S wrote:   
   > > On Sun, 11 Jan 2026 04:59:47 -0800   
   > > Keith Thompson  wrote:   
   > >   
   > >> Michael S  writes:   
   > >>> On Sat, 10 Jan 2026 22:02:03 -0500   
   > >>> "James Russell Kuyper Jr."    
   > >>> wrote:   
   > >>>> On 2026-01-09 07:18, Michael S wrote:   
   > >>>>> On Thu, 8 Jan 2026 19:31:13 -0500   
   > >>>>> "James Russell Kuyper Jr."    
   > >>>>> wrote:   
   > >>>> ...   
   > >>>>>> I'd have no problem with your approach if you hadn't falsely   
   > >>>>>> claimed that "It is correct on all platforms".   
   > >>>>>   
   > >>>>> Which I didn't.   
   > >>>>   
   > >>>> On 2026-01-07 19:38, Michael S wrote:   
   > >>>> ...   
   > >>>>   > No, it is correct on all implementation.   
   > >>>   
   > >>> The quote is taken out of context.   
   > >>> The context was that on platforms that have properties (a) and (b)   
   > >>> (see below) printing variables declared as uint32_t via %u is   
   > >>> probably UB according to the Standard (I don't know for sure,   
   > >>> however it is probable),   
   > >>   
   > >> I'm sure.  uint32_t is an alias for some predefined integer type.   
   > >>   
   > >> This:   
   > >>      uint32_t n = 42;   
   > >>      printf("%u\n", n);   
   > >> has undefined behavior *unless* uint32_t happens to an alias for   
   > >> unsigned int in the current implementation -- not just any 32-bit   
   > >> unsigned integer type, only unsigned int.   
   > >>   
   > >> If uint32_t is an alias for unsigned long (which implies that   
   > >> unsigned long is exactly 32 bits), then the call's behavior is   
   > >> undefined.  (It might happen to "work".)   
   > >>   
   > >   
   > > What exactly, assuming that conditions (a) and (b) fulfilled, should   
   > > implementation do to prevent it from working?   
   > > I mean short of completely crazy things that will make maintainer   
   > > immediately fired?   
   >   
   > If an architecture has 32-bit "unsigned long", then "unsigned int" is   
   > necessarily also 32-bit (since "unsigned int" is always at least   
   > 32-bit,   
      
   I am pretty sure that it is wrong.   
   C Standard does not require for 'unsigned int' to be above 16 bits.   
      
   > and "unsigned long" cannot be smaller than "unsigned int").   
   > The very fact that you listed "unsigned int is at least 32-bit wide"   
   > as an assumption shows you are not well versed with the basics of C   
   > standards in this area.   
   >   
      
   I am not well versed in the Standard. But in this particular case you   
   are the one who doesn't know it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)