From: david.brown@hesbynett.no   
      
   On 11/01/2026 20:58, Tim Rentsch wrote:   
   > Keith Thompson  writes:   
   >   
   >> 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.   
   >   
   > Very likely, but I don't think the C standard requires it.  TTBOMU   
   > the C standard allows the possibility of an implementation where   
   > uint32_t is type distinct from any other nameable type, and yet   
   > the implementation could still be conforming.   
      
   gcc for the AVR (or more accurately, the avrlibc library for the AVR   
   port of gcc) defines the various  types as "int" or "unsigned   
   int" with special modes giving their lengths (using a gcc-specific   
   extension).  I am never quite sure about the compatibility of these   
   types and other identically sized integer types.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)