Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!wilderland.ovh!ereborbbs.duckdns.org!eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Optimization by programmers Date: Sun, 27 Sep 2026 11:51:18 -0700 Organization: A noiseless patient Spider Lines: 54 Message-ID: <86ik3qr0ih.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> <868q4qsjdy.fsf@linuxsc.com> <11960cd$3lggg$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 27 Sep 2026 18:51:22 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1751259"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kgpjpcihbsBrWTgir/iMmjoV847XA4uk="; posting-host="2656c84029572b3033be2dff7a8e2cf2" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:5LVBRhpQMjOAdqimGz28sFNeuvI= sha1:ETfRZemFiNaOEX9V35NSgZdngIA= sha256:55MTvuK0bnCC+W3YBpsfB+1/Cc5z4Y6qKmeuCuXXZ/4= sha1:Nwrfs0xM0lAAyaJonew/30ER268= sha256:CusHZdQAgZm6BTkMzaACjiU+vmWwCP1ZWaHne7mHXPo= Xref: csiph.com comp.arch:118262 Stephen Fuld writes: > On 9/24/2026 9:29 AM, Tim Rentsch wrote: [...] >> [...] 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 have minimal experience with standards writing, and none with > language writing, so I may be off base here. > > I think that there are many situations where the standard, correctly, > doesn't specify anything about what the compiler should do. These are > currently called undefined behavior, and the standard essentially lets > it go at that - no further documentation required. > > But in many, but not all, of such cases, the compiler implementer > knows what it is going to do. What I am after is that in such cases, > the implementer "supplement" the bare words with information that he > has that knowledge and he should communicate it to the user. > > >> 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. > > Note that I am not trying to restrict "what happens" in any way. What > happens is anything that could/would happen under today's definition > of undefined behavior. I am just trying to ask the implementer, > whenever possible (and I realize that it is not always possible) to > elaborate on the bare words "undefined behavior". I want to write a short answer here. I trimmed away anything that looked incidental to my reply. The problem you want to solve is not a problem for the C standard; rather it is a problem with compilers and/or compiler writers. Because of that the C standard is not the right place to address it. The job of the C standard is to define the C language, and not to address questions of "how good" C implementations are. This property is a conscious and explicit decision made by the authors of the C standard. Any matters of "quality of implementation" are deliberately not addressed in the standard. I understand that you want to address what you see as a shortcoming in how compilers behave. Unfortunately the C standard is not the right venue to accomplish that, because how individual compilers behave is a quality of implementation concern, and not a question about what is the definition of the C language.