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: Wed, 23 Sep 2026 07:47:40 -0700 Organization: A noiseless patient Spider Lines: 24 Message-ID: <86pky4rpmb.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 23 Sep 2026 14:47:43 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1972655"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19udJM/rFV8AK9Mr6ugm/X/VwnF/4pmohw="; posting-host="e854bcdde9edbfa449147ac38d1c2707" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:SdoCg8t+qp6gLgc/jUzLcEeRkGE= sha1:7v1RxCqs2Z0b89gar9RBqa9H4hs= sha256:BUYNO740yJkD6m/82VOtgqhm4iZzeDEE+fTbLLl3rs0= sha1:ZAszthxELT1K+Y6WOQJQM9VuYGc= sha256:hHKACjoH5MHKYbIwPGeoaZye5csxV8lApZ3iRsUHjA8= Xref: csiph.com comp.arch:118148 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.