Re: Optimization techniques and runtime checks

On 12/05/2019 07:43, Gene Wirchenko wrote:
> On Wed, 8 May 2019 10:31:25 +0200, David Brown
> <david.brown@hesbynett.no> 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]

Return to the comp.compilers page.
Search the comp.compilers archives again.