From: already5chosen@yahoo.com   
      
   On Tue, 06 Jan 2026 16:29:04 -0800   
   Keith Thompson  wrote:   
      
   > 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?   
   >    
      
   No, I don't think that it is much uglier. At worst, I think that   
   correct version is tiny bit uglier. Not enough for beauty to win over   
   "correctness", even when correctness is non-consequential.   
      
   I hoped that you followed the sub-thread from the beginning and did not   
   lost the context yet. Which is (everywhere except LIN64)   
    uint32_t n = 42;   
    printf("n = %u\n", n);  // incorrect   
    printf("n = " PRIu32 "\n", n); // correct   
      
   or on LIN64   
    uint64_t n = 42;   
    printf("n = %llu\n", n);  // incorrect   
    printf("n = " PRIu64 "\n", n); // correct   
      
   Here in my book beauty wins by landslide.    
   Although really it is not beauty wins. It's ugliness loses.   
      
   > If unsigned int and unsigned long happen to be the same size, both   
   > are likely to print "42".  But what if your code is later compiled   
   > on a system with 32-bit unsigned int and 64-bit unsigned long?   
   >    
   > Even if I were certain the code would never be ported (and such   
   > certainty is often unjustified), I'd much rather use the correct   
   > code than waste time figuring out which incorrect code will happen   
   > to "work" on the current system, with the current version of the   
   > compiler and runtime library.  Oh, and gcc and clang both warn   
   > about an incorrect format string.   
   >    
   > I agree that the macros in  are ugly, and I rarely   
   > use them.  If I want to print an integer value whose type I don't   
   > know, I'll probably cast to a predefined type that I know to be   
   > wide enough and use the specifier for that type.  Though now that   
   > I think about it, I'm more likely to do that in throwaway code;   
   > for production code, I'd be more likely to use the  macros.   
   >    
   > [...]   
   >    
      
   I am happy that in practice your position is not too different from my   
   position. It's just that irresistible urge of you to defend "right"   
   things in NG discussions that creates an appearance of disagreeing.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)