Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: printf and time_t Date: Tue, 13 Jan 2026 00:53:36 -0800 Organization: None to speak of Lines: 52 Message-ID: <87cy3dq4fj.fsf@example.invalid> References: <10jfol6$2u6r8$1@news.xmission.com> <10jj9st$3jbe4$2@dont-email.me> <20260106200522.000015ea@yahoo.com> <87h5sy2rlb.fsf@example.invalid> <87qzs1gliq.fsf@example.invalid> <20260108012620.000041a9@yahoo.com> <87bjj5gei4.fsf@example.invalid> <20260108023846.0000260c@yahoo.com> <10jpi8h$15aea$1@dont-email.me> <20260109141859.00004f22@yahoo.com> <10jv3rb$15aea$2@dont-email.me> <20260111132015.000026ad@yahoo.com> <87ikd82tks.fsf@example.invalid> <20260111153201.000075f9@yahoo.com> <87ecnv3gj2.fsf@example.invalid> <10k27e7$25sqv$1@dont-email.me> <20260112110648.00002626@yahoo.com> <10k2pa0$2al6k$1@dont-email.me> <87h5sqpea7.fsf@example.invalid> <10k4trt$2vi9p$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 13 Jan 2026 08:53:38 +0000 (UTC) Injection-Info: dont-email.me; posting-host="0e64289da795cda92cb4be4d5bbb82c9"; logging-data="3160053"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ag1aIu8IDy7nqM52boqjC" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:s6mJWg8ecWSEvXOnz1nsppx56OU= sha1:SxkyHaN2DxdJloTHRXb0RX/x3Rk= Xref: csiph.com comp.lang.c:396387 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. >> 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. 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. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */