Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Spiros Bousbouras Newsgroups: comp.compilers Subject: Re: what is defined, was for or against equality Date: Sat, 8 Jan 2022 22:28:00 -0000 (UTC) Organization: A noiseless patient Spider Lines: 88 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-01-034@comp.compilers> References: <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> <22-01-016@comp.compilers> <22-01-018@comp.compilers> <22-01-020@comp.compilers> <22-01-027@comp.compilers> <22-01-032@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24246"; mail-complaints-to="abuse@iecc.com" Keywords: C, standards Posted-Date: 08 Jan 2022 17:58:29 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <22-01-032@comp.compilers> Xref: csiph.com comp.compilers:2810 On Sat, 8 Jan 2022 09:31:06 -0000 (UTC) Thomas Koenig wrote: > Spiros Bousbouras schrieb: > > On Thu, 6 Jan 2022 16:43:05 -0000 (UTC) > > Thomas Koenig wrote: > >> This is a rather C-centric view of things. The Fortran standard > >> uses a different model. > >> > >> There are constraints, which are numbered. Any violation of such > >> a constraint needs to be reported by the compiler ("processor", > >> in Fortran parlance). If it fails to do so, this is a bug in > >> the compiler. > >> > >> There are also phrases which have "shall" or "shall not". If this > >> is violated, this is an error in the program. Catching such a > >> violation is a good thing from quality of implementation standpoint, > >> but is not required. Many run-time errors such as array overruns > >> fall into this category. > > > > This seems to me exactly like the C model. What difference do you see ? > > First, I see a difference in result. Highly intelligent and > knowledgable people argue vehemently if a program should be able > to use undefined behavior or not, and lot of vitriol is directed > against compiler writers who use the assumption that undefined > behavior cannot happen in their compilers for optimization, > especially if it turns out that existing code was broken and no > longer works after a compiler upgrade (Just read a few of Linus > Torvald's comments on that matter). > > I see C conflating two separate concepts: Programm errors and > behavior that is outside the standard. "Undefined behavior is > always a programming error" does not work; that would make The C standard is in no position to say that some programme is in error. This would require near omniscience from the standard writers. > #include > #include > > int main() > { > char a[] = "Hello, world!\n"; > write (1, a, strlen(a)); > return 0; > } > > not more and not less erroneous than > > int main() > { > int *p = 0; > *p = 42; > } > > whereas I would argue that there is an important difference between > the two. The only difference I see between the two is that the first is defined by POSIX and the second is not. According to POSIX the first is required to print something on stdout. I cannot imagine any extension which would make the second programme do something useful and a conforming implementation may well compile it as essentially a no-op. But with something like int main(voidd) { int *p = 0 ; *p = 42 ; .... do other stuff ... return 0 ; } the C standard allows for a conforming implementation to do something useful like perhaps store 42 to address 0. > If the C standard replaced "the behavior is undefined" with "the > program is in error, and the subsequent behavior is undefined" > or something along those lines, the discussion would be much > muted. > > (Somebody may point out to me that this what the standard is > actually saying. If so, that would sort of reinforce my argument > that it should be clearer :-) No , it most definitely does not say that nor could it possibly say that.