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: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and runtime checks Date: Sun, 12 May 2019 20:17:32 +0200 Organization: A noiseless patient Spider Lines: 69 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-082@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-046@comp.compilers> <19-05-052@comp.compilers> <19-05-059@comp.compilers> <19-05-064@comp.compilers> <19-05-081@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="54469"; mail-complaints-to="abuse@iecc.com" Keywords: errors, comment Posted-Date: 12 May 2019 14:19:53 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-081@comp.compilers> Content-Language: en-GB Xref: csiph.com comp.compilers:2317 On 12/05/2019 07:43, Gene Wirchenko wrote: > On Wed, 8 May 2019 10:31:25 +0200, David Brown > wrote: > > [snip] > >> And often there is no way to handle run-time errors sensibly anyway. > > Rule 1 of handling run-time errors sensibily: > > DD EEE TTT EEE CC TTT TTT H H EEE M M ! > D D E T E C T T H H E MMM ! > D D EE T EE C T T HHH EE M M ! > D D E T E C T T H H E M M > DD EEE T EEE CC T T H H EEE M M ! > There are several points for handling run-time errors sensibly, and /all/ of them need to be in place - so there is no "rule number 1". You need to figure out what kinds of errors can occur, how you can detect them, and what you can do when you detect them. It is utterly pointless to start thinking about how to detect errors before figuring out what those errors might be! >> You don't want your car brakes to give you a message "Your braking >> system has encountered an integer overflow. Please report this error to >> your car dealer". You want the brake software developers to be >> /absolutely/ sure that overflows can't happen - and then there is no >> point in run-time checks. > > I have read too many stories about "This should never happen." > conditions happening. And I have seen too many examples of "just to be sure" run-time error checking that is never tested properly (how can you test something when the triggering circumstances can't happen?) and turns out to have bugs that cause trouble later. > >> Most probably no user will ever have a chance to report above error :-] > > Maybe not. Try a Web search -- I use duckduckgo.com myself -- > for: > honda brakes problem > > I do not know what the issue was. Ahem! I do not know what the > issues were. Apparently, there was a problem in 2009 or so and just > now. I know brake software has had bugs. (I find it hard to comprehend, but I know it is true.) Equally, I know that showing an error message on the car's screen for a software error is a useless idea. (Show messages when hardware, sensors, drivers, etc., have failed.) > > [snip] > >> Yes. I realise that this oddity is "for historical reasons". The same >> applies to a great many oddities in C. > > "Those who do not know history are condemned to repeat it." Those > who are stuck with unrevised standards are similarly condemned. > As are those who think detecting run-time errors is a substitute for writing code that does not generate these errors in the first place. [Back to compilers, please, unless we have some insight into how a compiler might address these problems. -John]