Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Optimization by programmers Date: Thu, 24 Sep 2026 09:29:13 -0700 Organization: A noiseless patient Spider Lines: 49 Message-ID: <868q4qsjdy.fsf@linuxsc.com> References: <1177fdi$26ea4$1@dont-email.me> <1736alhffrj7iuhfsesdo31bofc0m8pr12@4ax.com> <2026Sep11.083321@mips.complang.tuwien.ac.at> <6aa5876f.783937@news.eternal-september.org> <2026Sep12.201446@mips.complang.tuwien.ac.at> <6aa6172e.15711625@news.eternal-september.org> <2026Sep13.162747@mips.complang.tuwien.ac.at> <118h4cj$fi2a$1@dont-email.me> <2026Sep19.082513@mips.complang.tuwien.ac.at> <2026Sep21.191719@mips.complang.tuwien.ac.at> <118tshf$r2kv$1@dont-email.me> <118uv1g$18lk0$1@dont-email.me> <86pky4rpmb.fsf@linuxsc.com> <1193dsi$2pbdi$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 24 Sep 2026 16:29:14 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2989070"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Fq7yGxyB1xm0LKtYX85Fvb3zqtzqUMQ0="; posting-host="4f81a3025fe5b5b1edac6d1d2d74ab9d" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:OF3wxTGh62NL3F1A7F7JlGle81g= sha1:x4NtqryytCtYIMQEEtssnG6c7VU= sha256:zThc/gjaTam0kGS01N2Sc+RFBznDMwlaglr589scQvM= sha1:t6yTzlnHz1FcVDTwmC+SddXdPB0= sha256:K0tbSC4vW6S+Jv2UHg8hU2ZXi097UZd3iILGaIGIvq8= Xref: csiph.com comp.arch:118173 Stephen Fuld writes: > On 9/23/2026 7:47 AM, Tim Rentsch wrote: > >> Stephen Fuld writes: >> >>> On 9/22/2026 5:32 AM, David Brown wrote: >> >> [...] >> >>>> And note that in C23 the macro "unreachable()" was added with the >>>> sole semantics being "If a macro invocation unreachable() is >>>> reached during execution, the behavior is undefined" and "The >>>> program execution shall not reach such an invocation". >>> >>> I don't have a problem with the inclusion of "unreachable()", but >>> can you give a possible rationale for making its behavior >>> "undefined" as opposed to say "implementation defined"? Yes, it >>> would make the compiler implementers do some work to document >>> whatever they decided to do, but are there any other reasons? >> >> The short answer is that being implementation-defined is too >> limiting. A construct having implementation-defined behavior >> cannot do "just anything"; the C standard must specify what >> behavior choices are possible. Any fixed set of choices might >> rule out what an implementation would like to do. So the only >> way to allow implementations to do whatever they choose is to >> have the behavior be undefined. > > As I responded to David, you are right, given the way those terms are > defined in the standard. But I submit there should be some way to > express essentially "you can do whatever you want, but must document > what you do". Let's call the new behavior type "implementation dependent". Suppose an implementation gives documentation that says "If a program execution would encounter implementation-dependent behavior, then program execution may be affected in ways that are unpredictable, unknown, and/or unreliable." Question: are you okay with that? If not, how would you write a requirement in the C standard to limit the meaning of "you can do whatever you want, but you must document what you do" that gives only as much freedom as you think should be allowed? I think we will find that different people have very different ideas about how much freedom should be allowed in saying what happens. It's a very hard problem.