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: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Tue, 7 May 2019 16:03:04 +0200 Organization: A noiseless patient Spider Lines: 87 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-049@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> <19-05-037@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="24868"; mail-complaints-to="abuse@iecc.com" Keywords: C, standards Posted-Date: 07 May 2019 18:43:19 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2284 On 06/05/2019 14:25, Martin Ward wrote: > 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). If I write a function "square_root" in Go that takes a non-negative input and returns its square root, then calling that function with a negative input is undefined behaviour. It does not matter if it always has the same effect - if the behaviour has not been specified, it is undefined. Extrapolate that to any other aspect of any language, library, function, etc. > 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. > See above. It is certainly that case that many languages have /less/ undefined behaviour than C. It is certainly the case that many languages define the behaviour of particular things that are famously undefined in C, such as signed integer overflow (in many cases, the definitions are stupid and worse than useless - in other cases they may be useful but are inefficient). And it is certainly the case that less undefined behaviour can be useful - C is not the best choice of language for many tasks. >> 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. > Preconditions and postconditions are not just for proofs - they are specifications for the functions, and you should understand them for any operation or function you use. Certainly for many built-in functions and operations, it is possible to have a "true" precondition. But there /are/ reasons why you don't always want that. Different languages have different purposes. Checks and exceptions are not free. Some languages have checks and exceptions built in to save the programmer the effort, others require them to be written manually to give the programmer full control. >> 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!) Correct. > > How would you implement arithmetic MOD 2^32, MOD 2^64 or MOD 2^128 > if unsigned overflow was undefined? > When saying that undefined behaviour for unsigned overflow would make sense and be useful, I have usually also elaborated by saying you would need another method to get wrapping behaviour on the few occasions when you need it. I should have included this here too.