Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Re: Optimization techniques Date: Fri, 26 Apr 2019 19:46:53 +0100 Organization: Compilers Central Lines: 50 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-04-027@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <910eaf6f-f9ae-9c02-5052-f06474024d96@hesbynett.no> 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="54457"; mail-complaints-to="abuse@iecc.com" Keywords: design, optimize Posted-Date: 26 Apr 2019 15:14:19 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2211 On 25/04/19 20:58, David Brown wrote: > It is a serious mistake to mix up "defined behaviour" and "correct > behaviour". Only defined behaviour can be correct, but you can't fix > incorrect code by making it defined behaviour. "Defined behaviour" *can* be "correct behaviour" "undefined behaviour" can *never* be correct and therefore must be avoided at all costs. You dismiss cases of security holes due to undefined behaviour as "just program bugs, because programmers didn't do the right thing". The C ANSI standard is over 500 pages long and includes 199 different cases of undefined behaviour. A quick quiz: without referencing the standard, how many of the 199 cases of undefined behaviour can you list off the top of your head? Remember: a *good* programmer (one that you would describe as an engineer who knows what they are doing) must avoid all 199 cases of undefined behaviour in every line of code that they write. Dijkstra wrote this in his ACL Turing Award Lecture in 1972: "Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language -- our basic tool, mind you! -- already escapes our intellectual control." Note that even knowing that there is undefined behaviour, you still may not be able to avoid it by testing for its occurrence: the optimiser might spot that you are testing for undefined behaviour and optimise away your test, because it is allowed to assume that the undefined behaviour can never happen! (This is what actually occurred in the last example I gave). You say "The trick is to write the tests correctly" but don't tell us what clever tricks we can use in order to fool the optimised into thinking we are testing for something *other* than undefined behaviour and so head it off from optimising away our test. Even if we manage this: how can we be sure that the next version of the compiler will not include a cleverer optimiser which sees through our trickery and optimises away the test once again? There seems to be an arms race between programmers trying to write safe code and compiler writers detecting and optimising away their safety nets. -- 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