Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: New features added into C23 standard Date: Tue, 23 Aug 2022 13:40:49 -0700 Organization: A noiseless patient Spider Lines: 65 Message-ID: <864jy2u20e.fsf@linuxsc.com> References: <3093c98e-d014-47e4-bcf3-3f108d7c2c03n@googlegroups.com> <87mtcwzwt9.fsf@nosuchdomain.example.com> <88293f89-5f19-4fb3-844b-20e3a063b65cn@googlegroups.com> <86y1vou2yp.fsf@linuxsc.com> <86czcqud05.fsf@linuxsc.com> <871qt6zvm2.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="91c0bdac815ec2785494da3b56ec4ece"; logging-data="3247166"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cT4CiPBvTT+Dn3Y855h/kVC2wBEGlmeE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:nScUNDFMuO5sOyUMBmdophze+NA= sha1:5P6CXJABTmL3fIUOHTFxvYtVtxo= Xref: csiph.com comp.lang.c:167164 Keith Thompson writes: > Tim Rentsch writes: > >> Richard Damon writes: > > [...] > >>> The implementation can define ANYTHING it wants (as an extension), as >>> long as it doesn't violate a requirement of the Standard, and the >>> Standard explicitly provides no requirement on things it declares to >>> be Undefined Behavior, so an Implementation is free to define that >>> behavior as anything. >> >> Any construct that an implementation compiles, it defines. The behavior >> can be defined explicitly by documenting an extension, or it can be >> defined implicitly by what the generated code actually does. Either >> way, the implementation defines the behavior, but the point you are >> trying to make is not that. > > You can put it that way if you like, but the standard uses the > term "implementation-defined" specifically to refer to things that must > be documented, and "unspecified" to refer to things that may or may not > have to be documented. Yes, the C standard uses the terms "implementation-defined behavior" and "unspecified behavior" with very specific meanings, along with the corresponding shortenings "implementation-defined" and "unspecified". My point is to distinguish the usage of words "define" and "document" as they occur in ordinary English, and also to avoid using phrases that might be confused with how similar phrases are used in the C standard. > For unspecified and not implementation-defined behavior, the > choice of actual behavior might not even be deliberate. Sure. What behavior results might be an accidental, unconscious, unaware, unknowing, or even unexpected and unintended consequence of how the compiler is written. It is still the case that the compiler implicitly defines the behavior, by virtue of what choices are made to produce the compiled code. >>> [from a later posting] >>> Yes, unfortunately, the language of the Standard doesn't give a good >>> term for things the Implementation chooses to define but wasn't >>> required to define. >> >> Yes, it does. An implementation can document an extension that >> specifies the behavior of the construct in question. > > An implementation might, for example, document the order of evaluation > of the operands to "+". I don't think that would be considered an > extension (though the standard doesn't define the term "extension" > precisely). To my way of thinking any specification of behavior that goes beyond what the C standard mandates counts as an extension (provided of course it is documented), regardless of whether the additional semantics falls into the realm of unspecified behavior, undefined behavior, or even contradicts what the C standard says (assuming of course the change has no effect on any strictly conforming program). If the implementation wants to say that some additional semantic rules are in effect then that needs to be documented somewhere, and the only kinds of such documentation mentioned in the C standard are for implementation-defined behavior, and for extensions.