Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Mon, 6 May 2019 13:25:36 +0100 Organization: Compilers Central Lines: 45 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-037@comp.compilers> References: <19-05-014@comp.compilers> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-039@comp.compilers> <19-04-042@comp.compilers> <19-04-044@comp.compilers> <19-04-047@comp.compilers> <19-05-004@comp.compilers> <19-05-008@comp.compilers> <19-05-014@comp.compilers> <19-05-021@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="36158"; mail-complaints-to="abuse@iecc.com" Keywords: standards, errors Posted-Date: 06 May 2019 10:45:44 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <19-05-021@comp.compilers> Xref: csiph.com comp.compilers:2272 On 03/05/19 16:23, David Brown wrote: > There are lots of situations where behaviour is undefined, in /all/ > programming languages. The lower level and more efficient the language, > the more such situations you get - but none are entirely free of > undefined behaviour. There are many language in which all behaviour is defined: for example, Go has no undefined behaviour. Some behaviour may be "unspecified" (eg it could do X, or could do Y, but cannot do anything else). There is no logical requirement for leaving any behaviour undefined: other than laziness by the language designers, or an inability to reach agreement on a suitable behaviour. I believe Java also has no undefined behaviour. > You can prefer that languages have "true" preconditions for some > functions, but they certainly won't have it for all. Preconditions are used in proofs of correctness and in the specification of functions. In a correctness proof, you prove that for any initial state satisfying the given precondition, the program is guaranteed to terminate in a state which satisfies the given postcondition. For built-in functions and operations in a language definition there is no reason why the precondition cannot be "true", or the language could specify that an error message is returned or an exception raised if the function's precondition is not met. > I have regularly said that most unsigned overflows are also bugs, > and that undefined behaviour there would also make sense. This would appear to make it extremely difficult to implement two's complement arithmetic in C: currently one can cast the signed values to unsigned, calculate the result, and cast back to signed. (Note however that negative numbers are not guaranteed to be stored in two's complement format!) How would you implement arithmetic MOD 2^32, MOD 2^64 or MOD 2^128 if unsigned overflow was undefined? -- Martin Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4