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: Mon, 02 Mar 2026 18:04:13 -0800 Organization: None to speak of Lines: 41 Message-ID: <871pi1llcy.fsf@example.invalid> References: <10jfol6$2u6r8$1@news.xmission.com> <10jfs23$2liif$1@dont-email.me> <10jgc2t$2rp4s$2@nntp.eternal-september.org> <86o6n5pocw.fsf@linuxsc.com> <10jm6se$r6nl$1@dont-email.me> <864imyg0im.fsf@linuxsc.com> <10o54de$1i30i$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 03 Mar 2026 02:04:14 +0000 (UTC) Injection-Info: dont-email.me; posting-host="c4097d27e79d6fc37137612ff20aadd3"; logging-data="1751079"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ajwmKSalEJZJ/1a1wARVK" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:JnDg/H3FMIKHRRKqlkXNP4L3jhk= sha1:lEsMym8/JhsHIyvS5dZn5g4ihNE= Xref: csiph.com comp.lang.c:396732 James Kuyper writes: > Tim Rentsch writes: [...] >> Besides all of that, _Imaginary types don't satisify the condition >> for time_t to be an arithmetic type. Annex G says the imaginary >> types are floating types, but in C99 Annex G is informative, not >> normative. > > True, but if _Imaginary types are supported by an implementation, Annex > G describes what it is that is being supported. I don't see a problem, > though I'm sure that you do. > I hadn't remembered that the imaginary types were removed from the draft > version of C202X. They were still present in n3220.pdf, dated 2024. In > that version, Annex G (which describes imaginary types) is described as > normative. 7.3.1p6 indicates that they were optional in that version. > However, if they were supported, they did meet the requirements of an > arithmetic type. I don't have the official ISO C23 standard, but I understand that N3220 is quite close to it. In that draft, and I believe in the actual standard, Annex G is normative but optional. Implementations are not required to support it unless they define __STDC_IEC_559_COMPLEX__. (C23 changes the macro name to __STDC_IEC_60559_COMPLEX__ and makes the name __STDC_IEC_559_COMPLEX__ obsolescent.) C11 and C17 are similar. (As of C23, Annex G still says "There is a new keyword _Imaginary". It's hardly new; it goes back to C99.) As I understand it, a conforming implementation that defines __STDC_IEC_559_COMPLEX__ or __STDC_IEC_60559_COMPLEX__ *must* implement both complex and imaginary types. Neither gcc nor clang does so. C2y completely drops support for imaginary types. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */