From: jameskuyper@alumni.caltech.edu   
      
   On 2026-01-11 08: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?   
      
   I'm quite positive that you would consider anything that might give   
   unexpected behavior to such code to be "crazy". The simplest example I   
   can think of is that unsigned int is big-endian, while unsigned long is   
   little-endian, and I would even agree that such an implementation would   
   be peculiar, but such an implementation could be fully conforming to the   
   C standard.   
      
   >> If uint32_t and unsigned long have different sizes, it still might   
   >> happen happen to "work", depending on calling conventions.  Passing a   
   >> 32-bit argument and telling printf to expect a 64-bit value clearly   
   >> has undefined behavior, but perhaps both happen to be passed in 64-bit   
   >> registers, for example.   
   >>   
   >   
   > And that is sort of intimate knowledge of the ABI that I don't want to   
   > exploit, as already mentioned in my other post in this sub-thread.   
      
   Which is precisely what's wrong about your approach - it relies upon   
   intimate knowledge of the ABI. Specifically, it relies on unsigned int   
   and unsigned long happening to have exactly the same size and   
   representation.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)