home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,965 of 243,242   
   David Brown to Keith Thompson   
   Re: printf and time_t   
   12 Jan 26 08:34:02   
   
   From: david.brown@hesbynett.no   
      
   On 12/01/2026 07:47, Keith Thompson wrote:   
   > Michael S  writes:   
   >> On Sun, 11 Jan 2026 11:51:43 -0800   
   >> Tim Rentsch  wrote:   
   >>> Michael S  writes:   
   > [...]   
   >>>>          Properties are:   
   >>>> a) uint32_t aliased to 'unsigned long'   
   >>>> b) 'unsigned int' is at least 32-bit wide.   
   >>>   
   >>> It seems unlikely that any implementation would make such a   
   >>> choice.  Can you name one that does?   
   >>   
   >> Four out of four target for which I write C programs for living in this   
   >> decade:   
   >> - Altera Nios2 (nios2-elf-gcc)   
   >> - Arm Cortex-M bare metal (arm-none-eabi-gcc)   
   >> - Win32-i386, various compilers   
   >> - Win64-Amd64,various compilers   
   >   
   > I find that surprising.  I just tried a test program that prints   
   > the name of the type uint32_t is an alias for (using _Generic),   
   > and it's alias to unsigned int on every implementation I tried.   
   > (Your properties are limited to systems with 32-bit int and long.)   
   >   
      
   On 32-bit embedded systems, it is common for uint32_t to be unsigned   
   long, even though unsigned int is the same size.  It perhaps comes from   
   the pretty much universal definition of uint32_t as unsigned long for   
   smaller embedded systems where "int" is less than 32 bits.   
      
   On Linux systems, unsigned int seems more common even on 32-bit systems.   
     Thus 32-bit EABI ARM uses unsigned long, while 32-bit Linux ARM uses   
   unsigned int.   
      
   (Common, of course, does not mean guaranteed - there are no doubt   
   exceptions to the general pattern.)   
      
   > For an implementation where int and long are both 32 bits, it   
   > wouldn't have surprised me for uint32_t to be an alias either for   
   > unsigned int or for unsigned long, and I wouldn't care either way   
   > beyond idle curiosity, but all the implementations I've tried choose   
   > to use unsigned int.   
   >   
   >> Well, if I would be pedantic, then in this decade I also wrote several   
   >> programs for Arm32 Linux, where I don't know whether uint32_t is alias   
   >> of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux,   
   >> where I know that uint32_t is an alias of 'unsigned long' and may be one   
   >> program for ARM64 Linux that is the same as AMD64 Linux.   
   >> But all those outliers together constitute a tiny fraction of the code   
   >> that I wrote recently.   
   >   
   > One advantage of my approach is that I don't have to know or care   
   > what the underlying type of uint32_t is.   
   >   
      
   Indeed.   
      
   (I also write non-portable code where I /do/ know the underlying type -   
   so I might use "lu" directly for uint32_t.  But I know the code will not   
   be used on other targets, and I know I have the correct specifier for   
   the target I am using.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca