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: A thought of C Date: Thu, 23 Apr 2026 08:46:27 -0700 Organization: A noiseless patient Spider Lines: 49 Message-ID: <86eck54r3g.fsf@linuxsc.com> References: <3a3462bdd72c4ed9d392a78b7d369a7b5ccc3b04.camel@gmail.com> <10rtdpd$2g1i0$1@dont-email.me> <10rth24$2h2ls$1@dont-email.me> <10rtnud$2jfm5$1@dont-email.me> <10s01e1$384ct$1@dont-email.me> <10s06q2$39rhn$1@dont-email.me> <10s2a2u$3t0f5$1@dont-email.me> <10s2fhc$3ug5h$1@dont-email.me> <10s2h5f$3uctl$1@dont-email.me> <10s2oq0$19am$1@dont-email.me> <10s2tfe$2lvm$1@dont-email.me> <10s34f6$542f$1@dont-email.me> <10s3akj$7ajg$1@dont-email.me> <10s3otn$bk6v$1@dont-email.me> <10s5atn$2sck7$1@paganini.bofh.team> <86ik9j63hc.fsf@linuxsc.com> <10sal8n$2967c$2@dont-email.me> <20260422185252.00001a9b@yahoo.com> <86v7di4a6c.fsf@linuxsc.com> <20260423131509.00005e6d@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 23 Apr 2026 15:46:29 +0000 (UTC) Injection-Info: dont-email.me; posting-host="096db26766e75ae3d0da9ffd77dfc80c"; logging-data="3309331"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rDmIYb+Hmxzpg/Dp2niMWOAxQA1r8wWk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:oozQjr0VxuT9kksOozgQbjyyrWg= sha1:Ie70gQ4HzivK+V1yB4m8hYc/7pA= Xref: csiph.com comp.lang.c:397866 Michael S writes: > On Wed, 22 Apr 2026 20:39:39 -0700 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Wed, 22 Apr 2026 15:16:56 +0100 >>> Bart wrote: >>> >>>> On 22/04/2026 05:09, Tim Rentsch wrote: >>>> >>>>> antispam@fricas.org (Waldek Hebisch) writes: >>>>> >>>>>> You look at trivial example, where AFAICS the best answer is: >>>>>> "Compiler follows general rules, why should it make exception for >>>>>> this case?". Note that in this trivial case "interesting" >>>>>> behaviour could happen on exotic hardware (probably disallowed >>>>>> by C23 rules, but AFAICS legal for earlier C versions). >>>>> >>>>> The kinds of behavior Bart is asking about has been undefined >>>>> behavior for just over 15 years, since 2011 ISO C. >>>> >>>> So what was it between 1972 and 2011? >>> >>> My record at guessing exact meaning of Tim's statements is not >>> particularly good, but I'll try nevertheless. >>> >>> Tim seems to suggest that function foo() below had defined behavior >>> (most likely of returning 1) in C90 and C99, then it became >>> undefined in C11 and C17 then again became defined in C23. >>> For years 1972 to 1989 Tim probably thinks that there is no >>> sufficient data to answer your question. >> >> I'm curious to know what you think of my answer now that I >> have written one. :) > > I'd like to read an explanation of what exactly was changed or > clarified in 2011 and again in 2024. The main thing in C11 is that a specific scenario, related to the "Not a Thing" in Itanium, was spelled out and unambiguously labeled undefined behavior. The result wasn't so much of a change as it was a specific addition. I'm not paying much attention to C23 (which I guess was ratified in 2024). What I have read about C23 makes me think the people who are now responsible for the ISO C standard have lost the spirit of the original writings and original authors. Very sad.