On Sun, 12 Feb 2012 14:42:54 -0700 Paul Gilmartin <[email protected]>
wrote:
:>On Feb 13, 2012, at 05:16, robin wrote:
:>> The programming world is littered with "it can't happen" cases.
:>> Everyone knows Murphy's Law ("If anything can go wrong, it will").
:>> But not many have heard of Robert's Law? ("Even if it can't go wrong, it
will".)
:>> So, even it the length were tested prior, one can't assume that all
:>> will be well when the EX is reached.
:>What boundaries do you place on Robert's Law? Must the programmer
:>check for overflow after every fixed point operation, even when
:>it is known a priori that the operands are such that no overflow
:>is possible? How about:
:> SR R2,R2 Clear GR2
:> BO OVERFLOW_ERROR
:>??? (There's some argument here for using XR instead of SR for
:>this purpose if an automated style checker mandates the overflow
:>test.)
:>Hardware detection of arithmetic exceptions is a boon here. But
:>one ISV C compiler requires that the generated code be run with
:>fixed-point overflow interrupts disabled. Shame on the vendor!
I worked on code where the code checked for MVS (on an MVS only product) and
if it detected that it was not MVS attempted to issue MVS macros to report the
error. I bet that code was never exercised.
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
