Re: Optimization techniques and runtime checks

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 !


>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.


>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.


[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.


[snip]


Sincerely,


Gene Wirchenko
[This is defininitely far from compilers. The recent error is that a
system that's supposed to brake to avoid collisions somtimes brakes at
random in heavy traffic. Sounds like a bug but not one that could
have been optimized away. -John]

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