NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/programm/3099

Text File | 1992-11-10 | 4.0 KB | 86 lines

Newsgroups: comp.programming
Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
From: [e-mail] (Markku Sakkinen)
Subject: Re: Help - What Is Wrong?
Message-ID: <[e-mail]>
Organization: University of Jyvaskyla, Finland
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 10 Nov 1992 13:58:48 GMT
Lines: 75

In article <[e-mail]> [e-mail] (M. J. Saltzman) writes:
>Discussing a fragment of code of the form
>
>    for ( i = 0;  i != 5;  i++ )
>        ...
>
>[e-mail] (Richard M. Hartman) writes:
>>
>>I've always seen (and used) the "i<max" form of the for loop, and
>>messed up when faced w/ anything else.  "i!=max" WILL work, but
>>is less safe for a number of reasons (more so if initial condition
>    ^^^^^^^^^
>>is set by variable instead of literal).
>
>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).  His reasoning is that the failure of i to be
>less than 5 indicates an error elsewhere in the code, which might go
>undetected if the loop fails to execute at all (with the program
>giving a wrong answer).  If the program goes into an infinite loop,
>you can be sure you've stumbled on a bug.

Looks like pretty bad advice from such an acknowledged authority.
If catastrophic failure is required, it should be an abort or the like,
not an infinite loop.  Perhaps if the programmer herself is always
tending to her programme when it is run(!), she may reason:
"Far too much time has passed for this stage, it _must_ be stuck
in an infinite loop somewhere."
Infinite loops can be a particularly bad idea in multitasking systems.

In this specific example as is, there is not much difference
between the alternatives.  But suppose a little modification:
    for ( i = whiz(x);  i != 5;  i++ ) ...
will be sensible only if you are absolutely sure that 'whiz(x)'
returns a value < 5;  otherwise you should insert an explicit test.
On the contrary, 'i < 5' works perfectly also in this case,
if the intent is not to execute the loop at all if the value is >= 5.
Also, the code might be modified so that the increment is 2 instead of 1;
'i < 5' still works in a way that may be sensible.
In general, it looks much more robust than 'i != 5'.

>On the other hand, Gries recommends that guards on "if" and "else"
>statements should be as strong as possible, and that the default
>action for any case not explicitly covered in the guards should be to
>abort.  The reasoning is the same: if one of the "if" or "else"
>conditions is not met, there is a failure elsewhere in the program
>that could go undetected if the program is allowed to continue.

Obviously you are quoting from memory (see below), and this does
not make any sense.  'If ... then ... else ... endif'
always covers all cases!

>[1] This book is a classic, and a very readable introduction to the
>ideas underlying derivation of provably correct programs.  (Sorry, I
>don't have the publisher information handy.)

If Gries strongly suggests infinite loops in many places,
the book is evidently aiming at provably _partially_ correct programs. :-)

----------------------------------------------------------------------
Markku Sakkinen ([e-mail])
       [e-mail] (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------