From: david.brown@hesbynett.no   
      
   On 13/01/2026 12:45, Michael S wrote:   
   > 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.   
      
   As far as I know, ST uses ARM's gcc build as their normal toolchain.  I   
   haven't looked at TI's development tools for a good while.   
      
   But it is certainly the case that clang-based toolchains are gaining in   
   popularity for non-Linux embedded ARM.  I've been looking at them   
   myself, and see advantages and disadvantages.  However, I believe gcc is   
   still dominated by a large margin, and ARM makes regular releases of   
   complete toolchain packages (compiler, libraries, debugger, etc.).   
      
   > 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.   
   >   
      
   My experience is that the majority of microcontroller vendors provide   
   gcc toolchains as part of their default installations.  They used to   
   have their own gcc toolchain builds, or use third-parties like Code   
   Sourcery, but these days they usually use an off-the-shelf ARM package.   
   But several vendors are in a transition period where they are gradually   
   moving from established Eclipse-based tools towards VS Code tools, and   
   perhaps clang is either an option or default with their newer IDEs.   
   Those vendors provide, support and maintain both IDEs at the moment, but   
   sometimes detailed support for particular microcontrollers only exists   
   for one of them.   
      
   I agree that most developers will use whatever compiler comes as default   
   with their vendor-supplied IDEs.  Personally, I think that's fine for   
   getting started, or for quick throw-away projects.  For anything serious   
   I prefer to have the build controlled from outside the IDE (by a   
   makefile), using the toolchain I choose (typically the latest ARM gcc   
   toolchain when the project starts, then remaining consistent throughout   
   the lifetime of the project).  The IDEs can still be good editors, IDEs,   
   debuggers, etc.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)