Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: printf and time_t Date: Sun, 11 Jan 2026 11:58:47 -0800 Organization: A noiseless patient Spider Lines: 36 Message-ID: <86v7h7ly4o.fsf@linuxsc.com> References: <10jfol6$2u6r8$1@news.xmission.com> <10jfs23$2liif$1@dont-email.me> <20260105105138.00005f0a@yahoo.com> <10jgbp7$2vdjt$1@news.xmission.com> <10jgdu9$2t8dh$1@nntp.eternal-september.org> <10jhkso$3c9r2$3@nntp.eternal-september.org> <20260106112938.00004446@yahoo.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 11 Jan 2026 19:58:51 +0000 (UTC) Injection-Info: dont-email.me; posting-host="af31aae2f202a5674f65c79be352c26d"; logging-data="172910"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KpH/+p5KMtX4zmmNB1X1ExXX/IhT5Zc4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:pYJEHh1WdemkGmBXAoUqSE5t3TI= sha1:DD3aizfFY6Cxh3/xIrKuGovgl3w= Xref: csiph.com comp.lang.c:396350 Keith Thompson writes: > Michael S writes: > >> On Sat, 10 Jan 2026 22:02:03 -0500 >> "James Russell Kuyper Jr." wrote: >> >>> On 2026-01-09 07:18, Michael S wrote: >>> >>>> On Thu, 8 Jan 2026 19:31:13 -0500 >>>> "James Russell Kuyper Jr." wrote: >>> >>> ... >>> >>>>> I'd have no problem with your approach if you hadn't falsely >>>>> claimed that "It is correct on all platforms". >>>> >>>> Which I didn't. >>> >>> On 2026-01-07 19:38, Michael S wrote: >>> ... >>> >>>> No, it is correct on all implementation. >> >> The quote is taken out of context. >> The context was that on platforms that have properties (a) and (b) (see >> below) printing variables declared as uint32_t via %u is probably UB >> according to the Standard (I don't know for sure, however it is >> probable), > > I'm sure. uint32_t is an alias for some predefined integer type. Very likely, but I don't think the C standard requires it. TTBOMU the C standard allows the possibility of an implementation where uint32_t is type distinct from any other nameable type, and yet the implementation could still be conforming.