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