From: david.brown@hesbynett.no   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)