NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/c/16473

Text File | 1992-11-14 | 3.2 KB | 78 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!gumby!destroyer!gatech!hubcap!mjs
From: [e-mail] (M. J. Saltzman)
Subject: Re: Help - What Is Wrong?
Message-ID: <[e-mail]>
Followup-To: comp.programming
Organization: Clemson University, Clemson SC
References: <[e-mail]> <[e-mail]>
Date: Fri, 13 Nov 1992 18:20:44 GMT
Lines: 66

In article <[e-mail]> [e-mail] (Jim Miller) writes:
>>comp.lang.c / [e-mail] (M. J. Saltzman)
>>
>>Presumably, "i != 5" is "less safe" because a failure of the initial
>>condition to satisfy i < 5 will not result in an infinite loop
>>(especially if the initializer "i = 0" is replaced by, say, "i = j + 1",
>>or if the initial i is passed as a parameter).  On the other hand,
>>this may not be the best kind of "safety" to have.
>>
>>In _The_Science_of_Programming_[1], David Gries argues that the guards
>>on loops should be as weak as possible, so that if the initial
>>condition is violated, the program will fail catastrophically (i.e.
>>with an infinite loop).
>
>IMHO: yes and no.
>
>While unit testing, "i != 5" might be the better idea for the reasons stated,
>for *production* I'd choose "i < 5".  If the program can continue to limp
>along instead of crash/hang, the user may still be able to use it,
>they may be able to save their data, they may even be able to survive.
>
>[discussion of advantages of each form in various contexts deleted]

Of course, like any advice on *style*, this should be (and is, in the
book) prefaced with the clause, "All other things being equal, ..."
Which option is preferable depends a lot on the consequences of the
error that caused i to be > 5 in the first place.

There are situations where the error would not be severe and the
program could continue without causing major problems (I think these
would be real-time control systems), but there are many other
situations where the undetected error is the more dangerous outcome.
In record-keeping applications, such an error could cascade through
the system, causing a major problem.  In real-time systems, it might
be better for the system to fail, and/or return control to a human
operator, rather than to continue on an erroneous course.  Do you
follow comp.risks?

Also, as I pointed out in the discussion on comp.programming, I did
take the recommendation out of context.  The weak loop guard is also
a consequence of the program derivation method.  It has the advantage
in that context that its negation is strong, and proof of the loop
postcondition is simplified.

I think designing *robust* programs (that fail gently or recover when
errors are detected) is not exactly the same as designing *correct*
programs.

>Ok, David Gries and I disagree.
>So, an  expert  and I disagree.
>So, what else is new?  :-)

Well, all generalizations are false 8^), even those made by experts.

>
>   jim miller
>   [e-mail]
>   (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
>   Anything I say will be used against me ...
>   But my company doesn't know or approve or condone anything of mine here.


--
        Matthew Saltzman
        Clemson University Math Sciences
        [e-mail]