From: already5chosen@yahoo.com   
      
   On Wed, 07 Jan 2026 13:28:45 -0800   
   Keith Thompson  wrote:   
      
   > scott@slp53.sl.home (Scott Lurndal) writes:   
   > > Keith Thompson  writes:     
   > >>Michael S  writes:     
   > >>> On Tue, 6 Jan 2026 10:31:41 -0500   
   > >>> James Kuyper  wrote:     
   > >>>> On 2026-01-06 04:29, Michael S wrote:     
   > >>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)   
   > >>>> > Lawrence D’Oliveiro  wrote:       
   > >>>> ...     
   > >>>> >> Section 7.8 of the C spec defines macros you can use so you   
   > >>>> >> don’t have to hard-code assumptions about the lengths of   
   > >>>> >> integers in printf-format strings.       
   > >>>> >    
   > >>>> > Did you ever try to use them? They look ugly.       
   > >>>>    
   > >>>> Which is more important, correctness or beauty?     
   > >>>   
   > >>> It depends.   
   > >>>   
   > >>> When I know for sure that incorrectness has no consequences, like   
   > >>> in case of using %u to print 'unsigned long' on target with 32-bit   
   > >>> longs, or like using %llu to print 'unsigned long' on  target with   
   > >>> 64-bit longs, then beauty wins. Easily.     
   > >>   
   > >>Seriously?   
   > >>   
   > >>An example:   
   > >>   
   > >>    unsigned long n = 42;   
   > >>    printf("%u\n", n);  // incorrect   
   > >>    printf("%lu\n", n); // correct   
   > >>   
   > >>Are you really saying that the second version is so much uglier   
   > >>than the first that you'd rather write incorrect code?     
   > >   
   > > I suspect he may have been referring to code that needs   
   > > to build for both 32-bit and 64-bit targets.   One might   
   > > typedef 'uint64' to be unsigned long long on both targets   
   > > and just use %llu for the format string.  BTDT.     
   >    
   > In the quoted paragraph above, Michael wrote about using %u to print   
   > unsigned long, not about using %u to print some type hidden behind   
   > a typedef.  If he didn't mean that, he can say so.   
   >    
   > But even if he meant to talk about printing, say, uint64_t values,   
   > my point stands.   
   >    
   > I wouldn't define my own "uint64" type.  I'd just use "uint64_t",   
   > defined in .  And I'd use one of several *correct* ways   
   > to print uint64_t values.   
   >    
   > Michael, if you'd care to clarify, given:   
   >    
   >     unsigned long n = 42;   
   >     printf("%u\n", n);  // incorrect   
   >     printf("%lu\n", n); // correct   
   >    
   > (and assuming that unsigned int and unsigned long are the same width   
   > on the current implementation), do you really prefer the version   
   > marked as "incorrect"?   
   >    
      
   I hoped that I already clarified that point more than one time.   
   Obviously, I hoped wrong.   
      
   In the case I am talking about n declared as uint32_t.   
   uint32_t is an alias of 'unsigned long' on 32-bit embedded targets, on   
   32-bit Linux, on  32-bit Windows and on 64-bit Windows. It is   
   alias of 'unsigned int' on 64-bit Linux.   
   Sometimes I move code between targets by myself, sometimes, rarely,   
   other people do it. I don't want to have different versions of the code   
   and I don't want to use ugly standard specifiers. Between two pretty   
   and working variants I prefer the shorter one. Partly because it is   
   guaranteed to work correctly on all my targets, including LIN64, but   
   more importantly (in practice, 64-bit Linux is a very rare target in my   
   daily routine) just because it is shorter. And I don't care that it is   
   formally "incorrect" on my more common targets. Or may be not   
   "formally", but both gcc and clang think so.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)