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: Thu, 15 Jan 2026 18:17:54 -0800 Organization: None to speak of Lines: 59 Message-ID: <87ikd29u7h.fsf@example.invalid> References: <10jfol6$2u6r8$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> <10k71rl$15aeb$10@dont-email.me> <20260114111038.0000258e@yahoo.com> <10kahv8$f3eq$2@dont-email.me> <87ms2fnkzq.fsf@example.invalid> <10kc31m$17vvl$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 16 Jan 2026 02:17:55 +0000 (UTC) Injection-Info: dont-email.me; posting-host="6b41e047a510a41c293f0d4e2f3853b5"; logging-data="1352203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yqkGSPy+NLzweUOYbveTI" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Xa7GbjfGs45lN+J51VZHOt4S5qU= sha1:hix9QIpS/JTzGQIKtTZRYkUSzh4= Xref: csiph.com comp.lang.c:396436 James Kuyper writes: > On 2026-01-15 07:00, Keith Thompson wrote: >> James Kuyper writes: >> [...] >>> I'm not sure exactly what you intended. And, as I mentioned in another >>> sub-thread, I've worked for most of my career under rules that >>> prohibited me from writing code that depends upon the kinds of details >>> that you're talking about - as a result, I've had little reason to >>> familiarize myself with those details. However, I can say that using >>> "%u" to print a value of unsigned long type has no chance of working >>> unless unsigned int and unsigned long have the same size and >>> representation. Even if they do, the behavior is still undefined, but >>> there's a pretty good chance it will work. >> [...] >> >> On one implementation (gcc, glibc, 64 bits), it *can* "work": >> >> ``` >> #include >> int main(void) { >> unsigned long x = 123456789; >> printf("sizeof (unsigned) = %zu\n", sizeof (unsigned)); >> printf("sizeof (unsigned long) = %zu\n", sizeof (unsigned long)); >> printf("x = %u\n", x); >> } >> ``` >> >> The output on my system (after some compiler warnings): >> >> ``` >> sizeof (unsigned) = 4 >> sizeof (unsigned long) = 8 >> x = 123456789 >> ``` >> >> Apparently printf tries to grab a 32-bit value and happens to get >> the low-order 32 bits of the 64-bit value that was passed. A value >> exceeding LONG_MAX is not printed correctly, but in principle it >> could be. > > I knew about that possibility, and had intended to word my comment to > cover it, but I forgot. Thanks for covering it. The key point is that > this only works for a large but limited range of values - it cannot work > in general. I suppose it depends on just what you mean by "in general". A conforming implementation *could* always print the mathematically correct value of a 64-bit unsigned long argument when printf is called with a 32-bit "%u" format. I could speculate about how this might work, but it doesn't really matter. Probably few if any implementations behave this way, but the nature of undefined behavior is that there is no behavior that violates the C standard. And of course the best advice is "don't do that". -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */