Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: what is defined, was for or against equality Date: Fri, 7 Jan 2022 12:06:12 +0100 Organization: A noiseless patient Spider Lines: 68 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-01-026@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="30588"; mail-complaints-to="abuse@iecc.com" Keywords: standards, semantics Posted-Date: 07 Jan 2022 20:24:03 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-020@comp.compilers> Content-Language: en-GB Xref: csiph.com comp.compilers:2802 On 06/01/2022 17:43, Thomas Koenig wrote: > David Brown schrieb: > >> There is no need to memorize undefined behaviours for a language - >> indeed, such a thing is impossible since everything not defined by a >> language standard is, by definition, undefined behaviour. (C and C++ >> are not special here - the unusual thing is just that their standards >> say this explicitly.) > > 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. C has basically the same concept. (IIRC, C++ as a few constraints such as the "one definition rule" that where the standard says no diagnostics are necessary, because identifying the error would mean the compiler has to see multiple translation units at once. Compilers often diagnose these if they have some kind of link-time optimisation or program-at-once mode.) > > 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. That is the same in C. From 4.2 "Conformance" : """ If a “shall” or “shall not” requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words “undefined behavior” or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe “behavior that is undefined”. """ The only difference I see from what you describe of Fortran (I have not read any Fortran standards) is that the C standards also note that behaviour that is not defined in the standards is undefined behaviour as far as the standards are concerned. That is a tautology, of course, and applies equally to Fortran and any other language. It is quite possible that the details of which behaviours are defined or not varies between the languages - things like division by 0, out-of-bounds array access, etc., may be different. As I understand it, passing aliased pointers or array references as different parameters to the same function can lead to undefined behaviour in Fortran, whereas it is defined in C (unless you use "restrict"). > [...] > >> The real challenge from big languages and big standard libraries is not >> /writing/ code, it is /reading/ it. It doesn't really matter if a C >> programmer, when writing some code, does not know what the syntax "void >> foo(int a[static 10]);" means. (Most C programmers don't know it, and >> never miss it.) But it can be a problem if they have to read and >> understand code that uses something they don't know. > > Agreed.