From: already5chosen@yahoo.com   
      
   On Tue, 13 Jan 2026 11:09:55 +0100   
   David Brown  wrote:   
      
   > On 13/01/2026 09:53, Keith Thompson wrote:   
   > > David Brown  writes:   
   > >> On 13/01/2026 01:06, Keith Thompson wrote:   
   > >>> David Brown  writes:   
   > >>> [...]   
   > >>> Context: %wN and %wfN printf length modifier, new in C23.   
   > >>>   
   > >>>> 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.)   
   > >>> Of course printf is implemented in the library, not in the   
   > >>> compiler.   
   > >>   
   > >> Primarily, yes.  But like all standard library functions, compilers   
   > >> can have special handling in some ways.  This is more obvious for   
   > >> functions like memcpy, where the compiler can often generate   
   > >> significantly better code (specially for small known sizes).  As   
   > >> far as I know, the only optimisation gcc does on printf is turn   
   > >> something like printf("Hello\n") into puts("Hello").   
   > >> Hypothetically, there is nothing to stop a compiler being a great   
   > >> deal more sophisticated than that, and doing the format-string   
   > >> interpretation directly in some way.   
   > >   
   > > Sure, but in practice the library support for printf is the only   
   > > thing that matters.  If your library doesn't support %wN, having   
   > > the compiler recognize it doesn't help.  I'm not sure why you even   
   > > mentioned gcc in this context.   
   > >   
   >   
   > I had several reasons (I would want compiler checking of the format   
   > before using it, I know the state of support in gcc, and I had   
   > mentioned ARM's gcc toolchains as they are the standard choice of   
   > toolchains for embedded ARM systems).   
      
   [O.T.]   
   AFAIK, that's no longer the case. For last 3-4 years Cortex-M MCU   
   vendors, in particular STMicro and TI, intensely push clang as a default   
   compiler in their free IDEs.   
   Today, in order to use gcc in the new embedded ARM project, developer   
   has to make a conscious effort of rejecting vendor's default. Most   
   likely, gcc compiler does not come as part of default installation   
   package. It has to be downloaded and installed separately.   
   I would guess that overwhelming majority of devs does not bother.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)