Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Gene Wirchenko Newsgroups: comp.compilers Subject: Re: Optimization techniques and error detection Date: Fri, 03 May 2019 10:16:26 -0700 Organization: A noiseless patient Spider Lines: 39 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-022@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-052@comp.compilers> <19-05-002@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="9459"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, errors Posted-Date: 03 May 2019 14:00:10 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:2257 On Wed, 1 May 2019 09:20:23 +0200, David Brown wrote: >On 01/05/2019 03:24, Gene Wirchenko wrote: >> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown >> wrote: >> >> [snip] >> >>> If you are writing your code in a "C with the extra feature of having >>> defined behaviour on signed integer overflow", and only compile it with >>> suitable compilers (or compiler flags), then that's okay. But don't >>> call it correct C code and blame compilers for your own mistakes or >>> unwarranted assumptions. >> >> I would like to see it as part of the language. I *know* that I >> want to have an error be thrown at run-time if an error can be >> detected. (It is not an unwarranted assumption.) It is not as if >> detecting signed integer overflow is a difficult thing on, for >> example, System/370, which also dates from 1970. > >Detecting signed overflow at run-time can be a significant cost. It Not detecting it can have a significant cost, too. Incorrect results can cost. > ... >No, throwing an error on overflows is not hard - but it /is/ costly. It >can be a marvellous tool during testing and debugging, and may be worth >leaving active in some programs, but it has a price. I do not deny it has a price, but I do not care about the price. I want the correctness. Others have different priorities: fine, but I want my priorities dealt with, too. Sincerely, Gene Wirchenko