From: david.brown@hesbynett.no   
      
   On 12/01/2026 10:06, Michael S wrote:   
   > On Mon, 12 Jan 2026 08:21:43 +0100   
   > David Brown  wrote:   
   >   
   >> On 11/01/2026 23:56, Keith Thompson wrote:   
   >>> Michael S  writes:   
   >>   
   >>>> The solution that I would prefer would be universal adaption of   
   >>>> Microsoft's size specifiers I32 and I64. They are not going to win   
   >>>> beauty competition, but in practice they are a lot more convenient   
   >>>> to use than standard macros and are equally good at carrying   
   >>>> programmer's intentions.   
   >>>   
   >>> The relative beauty of a feature that isn't available hardly seems   
   >>> relevant.   
   >>>   
   >>> The ideal solution is to write correct, and preferably portable,   
   >>> code in the first place.  There are often good reasons to write   
   >>> non-portable code, but I suggest that fiding the correct format   
   >>> string to be ugly is not one of them.   
   >>>   
   >>> (Microsoft's documentation says that "I32" prefix applies to an   
   >>> argument of type __int32 or unsigned __int32.  I don't know whether   
   >>> __int32 is compatible with int, with long, or neither, and I don't   
   >>> much care.  I don't know what Microsoft guarantees about printf   
   >>> with incompatible types that happen to have the same size.)   
   >>>   
   >>   
   >> C23 includes length specifiers with explicit bit counts, so "%w32u"   
   >> is for an unsigned integer argument of 32 bits:   
   >>   
   >> """   
   >> wN Specifies that a following b, B, d, i, o, u, x, or X conversion   
   >> specifier applies to an integer argument with a specific width where   
   >> N is a positive decimal integer with no leading zeros (the argument   
   >> will have been promoted according to the integer promotions, but its   
   >> value shall be converted to the unpromoted type); or that a following   
   >> n conversion specifier applies to a pointer to an integer type   
   >> argument with a width of N bits. All minimum-width integer types   
   >> (7.22.1.2) and exact-width integer types (7.22.1.1) defined in the   
   >> header  shall be supported. Other supported values of N are   
   >> implementation-defined. """   
   >>   
   >> That looks to me that it would be a correct specifier for uint32_t,   
   >> and should also be fully defined behaviour for unsigned int and   
   >> unsigned long if these are 32 bits wide.   
   >>   
   >   
   > It sounds very good.   
   >   
   > Except that none of my four targets of major interest supports C23 at   
   > the moment. Esp. so at the level of standard library.   
   >   
      
   gcc has supported the format, along with much of C23, since gcc 13, and   
   ARM's gcc-based toolchain version 13.2 is from October 2023.  (The   
   current version is 15.2 from December 2025.)  But I don't know about   
   library support - that is a very different matter.  (Compiler support   
   for printf really just means checking the format specifiers match the   
   parameters.)   
      
   It is an unfortunate fact of developers' lives that we see fun new   
   features in new language standards, but often have to wait years before   
   we can play with them.   
      
   > For one of them (Nios2) in the absence of something VERY unexpected   
   > there never be support (gcc stopped support for Nios2 2 or 3 years ago).   
   >   
   > For the other three, it will take time. I can't even guess how long,   
   > except that I know that support versions of arm-none-eabi-gcc lags two   
   > years behind "hosted" x86-64 and ARM64 versions, so I can guess that it   
   > would take significant time to catch up.   
   >   
      
   ARM's gcc-based toolchain builds are not nearly as far behind as they   
   used to be.  They have pretty much caught up to current stable gcc releases.   
      
      
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)