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: Tue, 03 Feb 2026 07:47:51 -0800 Organization: A noiseless patient Spider Lines: 64 Message-ID: <86ms1pj0bc.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> <86zf6kkjw0.fsf@linuxsc.com> <20260111235104.00001463@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 03 Feb 2026 15:48:00 +0000 (UTC) Injection-Info: dont-email.me; posting-host="72e789f1a61a439ff5daaffc25398413"; logging-data="1689774"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XRTBnYnedSfrXQNk2xxvn1DgtM+NQ3Mg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:/teOgiTDJywlJj18pvMe/TKL9HI= sha1:lnA6g6174i0ZrHnZQCp5d6O/6xM= Xref: csiph.com comp.lang.c:396575 Michael S writes: > On Sun, 11 Jan 2026 11:51:43 -0800 > Tim Rentsch wrote: > >> 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), but it can't cause troubles with >>> production C compiler. Or with any C compiler that is made in >>> intention of being used rather than crafted to prove theoretical >>> points. Properties are: >>> a) uint32_t aliased to 'unsigned long' >>> b) 'unsigned int' is at least 32-bit wide. >> >> It seems unlikely that any implementation would make such a >> choice. Can you name one that does? > > Four out of four target for which I write C programs for living in this > decade: > - Altera Nios2 (nios2-elf-gcc) > - Arm Cortex-M bare metal (arm-none-eabi-gcc) > - Win32-i386, various compilers > - Win64-Amd64,various compilers Interesting. I wonder what factors motivated such a choice. > Well, if I would be pedantic, then in this decade I also wrote several > programs for Arm32 Linux, where I don't know whether uint32_t is alias > of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux, > where I know that uint32_t is an alias of 'unsigned long' and may be one > program for ARM64 Linux that is the same as AMD64 Linux. > But all those outliers together constitute a tiny fraction of the code > that I wrote recently. If variable 'u' is declared as uint32_t, a way to print it that is easy and also type-safe is printf( " u is %lu\n", u+0LU );