home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,990 of 243,242   
   David Brown to Keith Thompson   
   Re: printf and time_t   
   13 Jan 26 11:09:55   
   
   From: david.brown@hesbynett.no   
      
   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).  But I had not intended it to be the focus, since   
   library support is the critical point.  (newlibc, as far as I can tell,   
   does not yet support it.)   
      
   >>> gcc has had format checking for %wN and %wfN since release 13, but   
   >>> that's useless in the absence of library support.   
   >>   
   >> Yes.   
   >>   
   >>> Support in glibc was added 2023-06-19 and released in version 2.39.   
   >>> Other C library implementations may or may not support it.   
   >>   
   >> glibc is not particularly relevant for non-Linux embedded   
   >> systems. newlib (and newlib-nano) are a common choice for such   
   >> systems, but I have no idea if it currently has support for those   
   >> formats.   
   >   
   > Of course, that's why I mentioned other C library implementations.   
   > glibc happens to be the one about which I had some relevant   
   > information.   
   >   
      
   Fair enough.   
      
   > The versions of musl and dietlibc that I have on my Ubuntu system   
   > don't support %wN.  The version of newlib I have on Cygwin also   
   > doesn't support it.  PellesC on Windows does.   
   >   
      
   musl and dietlibc are not suitable for non-Linux embedded systems   
   either, but of course it is nice to see the progress of support in   
   different libraries for different systems.  (And newlibc doesn't support   
   it yet - at least, not according to the online documentation.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca