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 09:43:22 -0700 Organization: A noiseless patient Spider Lines: 58 Message-ID: <86czcqud05.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="91c0bdac815ec2785494da3b56ec4ece"; logging-data="3195070"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zO5RM1JHtEdgsVQhc64y++/hOGDltSQg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:WB5+xi72DRMlymm0uS/NvI0qHkw= sha1:avgGBaq6vk8j778guWLmLPIodgU= Xref: csiph.com comp.lang.c:167152 Richard Damon writes: > On 8/16/22 2:17 AM, Tim Rentsch wrote: > >> Richard Damon writes: >> >>> On 7/31/22 5:12 AM, David Brown wrote: >>> >>>> It is also not uncommon in microcontrollers for address zero to be a >>>> useful address - and then it is user code that needs access. But it >>>> is rarely an issue in practice. The most common situation is having >>>> it as part of the flash for code, and it is typically part of the >>>> interrupt vectors or reset vector. You would only want to read it >>>> for something like a CRC check of the flash, and if you are >>>> concerned about the compiler handling a pointer to address zero in >>>> an unhelpful manner, you can use a pointer-to-volatile. The other >>>> cases I have seen are having memory mapped peripherals there - and >>>> again, you always use volatile accesses. >>> >>> And for machine specific case like this, the fact that derefencing a >>> NULL pointer is "just" Undefined Behavior, that can be Implementaton >>> Defined to do what is wanted, as opposed to some how PROHIBITED. >> >> Dereferencing a null pointer is unequivocally undefined behavior. >> It is never implementation-defined behavior. Even if an >> implementation defines and documents an extension that specifies >> a behavior for dereferencing a null pointer, as the C standard >> defines the terms such cases fall under the heading of undefined >> behavior, and not implementation-defined behavior. > > Note, I didn't say that it was "Implementation Defined Behavior", but > Undefined Behavior that the implementation can define. The C standard frequently uses the adjectival phrase "implementation defined" (normally with a hyphen) to mean implementation-defined behavior. I understand the point you're trying to make. My complaint is not with the point but with the language you are using to express it. > 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. > [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.