From: already5chosen@yahoo.com   
      
   On Tue, 13 Jan 2026 14:32:45 +0100   
   David Brown  wrote:   
      
   > 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.   
   >   
      
   You are right.   
   I downloaded the latest version of ST CubeIDE (2.0.0).   
   It claims to support STARM-Clang (not that I figured out how exactly),   
   but gcc is a default toolchain, same like in 1.x   
   I played with it for a few minutes then uninstalled as fast as I can.   
      
   > 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.   
   >   
      
   For me Eclipse-based IDE is slower and harder to use than command line   
   in any situation.   
   Although I am ready to admit that TI did better job than most of   
   turning Eclipse into something almost palatable.   
   Still, even Eclipse in form of TI's CCS is an obstacle for me rather   
   than help.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)