From: wyniijj5@gmail.com   
      
   On Fri, 2026-01-09 at 13:49 +0100, David Brown wrote:   
   > On 09/01/2026 13:18, Michael S wrote:   
   > > On Thu, 8 Jan 2026 19:31:13 -0500   
   > > "James Russell Kuyper Jr."  wrote:   
   > >    
   > > > On 2026-01-07 19:38, Michael S wrote:   
   > > > > On Wed, 07 Jan 2026 16:00:19 -0800   
   > > > > Keith Thompson  wrote:   
   > > > ...   
   > > > > > So you'd write code that happens to work on some implementations   
   > > > > > rather than code that's correct on all implementations.   
   > > > > >      
   > > > >    
   > > > > No, it is correct on all implementation. Idea that in C, as opposed   
   > > > > to C++, two unsigned integer types of the same size are somehow   
   > > > > different is, IMHO, an abomination. And that is one not especially   
   > > > > common case in which I don't care about opinion of the Standard.   
   > > >    
   > > > We're not talking about two unsigned integer types with same size.   
   > > > We're talking about unsigned long, which can be any size >= 32 bits,   
   > > > and uint32_t, which can only be exactly 32 bits. Your code is NOT   
   > > > portable to a platform where unsigned long is greater than 32 bits.   
   > > >    
   > >    
   > > I don't know how you came to discussions of what is possible.   
   > > My statement was concrete. It was about platforms like Windows (of all   
   > > flavors) and 2-3 specific 32-bit embedded targets that I currently   
   > > care about.   
   > > On all these platforms uint32_t is alias of 'unsigned long' which is   
   > > 32-bit wide. 'unsigned int' is also 32-bit wide.   
   > > I claim that *on these platforms* uint32_t and 'unsigned int' are *not*   
   > > different types. I don't care to what the Standard says about it.   
   >    
   > Of course they are different types.  In C, "unsigned int" and "unsigned    
   > long" are different types.  The standard says so - and it is the    
   > standard that defines the language.   
   >    
   > > I do care about what gcc says about it because I am annoyed by warnings   
   > > that I consider pointless.   
   >    
   > The warnings are not pointless, despite what you might think.  And of    
   > course gcc is not going to modify its warnings to pander to someone who    
   > has their own personal ideas about what C should be.  We /all/ have    
   > ideas about how C could be better for our own needs.  But outside the    
   > realm of personal languages where the single user also designed the    
   > language and wrote the compiler, you have to work with the language as    
   > it is defined.   
   >    
   > For a clear example of the differences between unsigned int and unsigned    
   > long, look at the generated code here:   
   >    
   >    
   >    
   > That is for embedded 32-bit ARM, where "uint32_t" is "unsigned long",    
   > and is the same size as "unsigned int".  Then try swapping the compiler    
   > to the 32-bit ARM gcc Linux version - here "uint32_t" is "unsigned int",    
   > and again the same size as "unsigned long".  Look at the differences in    
   > the code.   
   >    
   > It doesn't matter if /you/ think that all 32-bit integer types should be    
   > the same - in C, they are not.  And therefore in C compilers, they are    
   > not the same.   
   >    
   > >    
   > > Printing uint32_t values on these platforms with %u specifier, apart   
   > > from advantage of being shorter, has advantage of being undoubtedly   
   > > correct on LIN64. Unlike printing with %lu.   
   >    
   > But printing uint32_t with "%u" on 32-bit EABI ARM is not correct - it    
   > is UB.  It will /probably/ work, but maybe some day you will come across    
   > a situation where it will not.   
   >    
   > I have a lot of trouble understanding why you would go out of your way    
   > to knowingly write incorrect code - prioritising tiny, irrelevant    
   > savings in source code space over correct, guaranteed, portable code    
   > that can be automatically checked by tools.   
      
   Snipet from ClassGuidelines.txt   
      ...   
      wrd(or notation)   
              This function converts the argument object (a type, class,..) to   
   text   
              which can be used to construct the 'same' (including verified by   
              operator==) object.   
      
              Note: This function is not mandatory. But in OO design, the text   
                    may include the description of interactions between external   
                    events and sub-classes. This would form the basic proof of   
                    correctness of concept.   
      
   My reply might not be directly in the topic of current post. Just jumpped in   
   to reply. It looks to me the format character MUST match the type passed to    
   printf, otherwise UB.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)