bug me now / bug me later

bug me now / bug me later

[Jim Harkins]

Lets say you have the following (you ADA people, please bear with me):

	#define SIZE	6
	#define STEP	2

Which is better:

	a.	for(i = SIZE; i != 0; i -= STEP)
or
	b.	for(i = SIZE; i > 0; i -= STEP)

Where this makes a difference is suppose SIZE is changed to 7.  Obviously
'a' goes into an infinite loop, while 'b' stops.  In the real world SIZE and
STEP could be variables that have been input by a user and manipulated a
gazillion times before being used in the for loop.

With method 'a' a bug is easy to spot, thus easy to fix.  But the bug may not
appear at a good time, the user may prefer that his system limp along rather
than hang completely.

With method 'b' the bug is harder to spot.  If you test your code well you
should catch these things, but a man named Murphy became famous anyway.  I
believe method 'b' is preferred by 'defensive programmers'.  It is also
possible that with method 'b' the loop body stomps over somebody elses
memory, with unknown but probably bad results.


So, how do you all feel about this?  As I'm writing for a military contract
I've cross-posted this to comp.lang.ada, I hope they don't get too upset.  And
please hurry, this came up for a reason :-)


-- 
jim		jharkins@sagpd1

I hate to see you go, but I love to see you walk away.

Re: bug me now / bug me later

[Charles H. Sampson]

In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:
>
>Lets say you have the following (you ADA people, please bear with me):
>
>	#define SIZE	6
>	#define STEP	2
>
>Which is better:
>
>	a.	for(i = SIZE; i != 0; i -= STEP)
>or
>	b.	for(i = SIZE; i > 0; i -= STEP)
>
>Where this makes a difference is suppose SIZE is changed to 7.  Obviously
>'a' goes into an infinite loop, while 'b' stops.  In the real world SIZE and
>STEP could be variables that have been input by a user and manipulated a
>gazillion times before being used in the for loop.
>
     Neither is inherently better than the other; it depends on the problem.
If the problem requires that SIZE be a multiple of STEP, then a is preferable
because it reflects the problem requirement, but the requirement itself must
be validated at some point.  If there is no required relation between SIZE
and STEP, then b reflects that fact and is preferable.  (Of course, a is
wrong in the latter case, so b is strongly preferable.)

     All of this is MHO, naturally.

                               Charlie Sampson, CSC

P. S.  Anything written down here can be ignored.  The poster would not ac-
cept my followup because I had included more than I had written.  Strange,
I thought I had cut down the original article to the minimum needed to es-
tablish the context, then gave a compact response.  Apparently that's not
good enough.  The only solution in such a case seems to be to pad your
followup enough to get past that limitation.  Seems to me that the limita-
tion is self-defeating.  This is the end of my first try at padding.

Re: bug me now / bug me later

[Wade Richards]

In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:
=}
=}Lets say you have the following (you ADA people, please bear with me):
=}
=}	#define SIZE	6
=}	#define STEP	2
=}
=}Which is better:
=}
=}	a.	for(i = SIZE; i != 0; i -= STEP)
=}or
=}	b.	for(i = SIZE; i > 0; i -= STEP)
=}

It depends on the situation. 

If you know that i will exactly equal zero (as in this case), then I think
that's what you should test for.  However, I would probally put:

assert( SIZE % STEP == 0 )

before the loop, to make sure nothing blows up, and (more importantly) to make
it quite clear what was at fault if it does blow up.


	--- Wade

Re: bug me now / bug me later

[Robert Firth]

In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:

>Which is better:
>
>	a.	for(i = SIZE; i != 0; i -= STEP)
>or
>	b.	for(i = SIZE; i > 0; i -= STEP)
>
>Where this makes a difference is suppose SIZE is changed to 7.  Obviously
>'a' goes into an infinite loop, while 'b' stops.  In the real world SIZE and
>STEP could be variables that have been input by a user and manipulated a
>gazillion times before being used in the for loop.

First, the coding of the loop should have nothing to do with the values
of SIZE and STEP.  The code you write should be determined by the
postcondition you wish to establish.  If the required postcondition
is "i=0" then the correct continuation test is "i/=0"; on the other
hand if the required postcondition is "i<=0" then the test is "i>0".
This would all be much clearer in a language that allowed the condition
to be written positively, thus:

	loop
	  ...
	  exit when i=0
	end loop

	-- postcondition: i=0

Secondly, the question of errors.  If the loop variable reaches a state
from which the postcondition is unreachable, there is an error in the
code.  For example, if the postcondition is "i=0", the recurrence
relation "i'<i" (ie the new value of i will be strictly less than the
old value), and the current value of i is negative, then the postcondition
will never be reached.  If you suspect this can happen, you should test
for the situation, *but this test should be separate from the loop
termination test and not merged with it*.  The reason is that, if the
test fails, the last thing you want to do is terminate the loop silently
with the postcondition false.  You probably want to raise an exception,
enter a recovery block, or take some similar emergency action.

Hope that helps.

Re: bug me now / bug me later

[brnstnd]

In article <7498@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
> In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:
> >	a.	for(i = SIZE; i != 0; i -= STEP)
> >	b.	for(i = SIZE; i > 0; i -= STEP)
> First, the coding of the loop should have nothing to do with the values
> of SIZE and STEP.  The code you write should be determined by the
> postcondition you wish to establish.

Say what? Who cares what the value of i is after the loop? Most of the
time I want to see i uninitialized the moment the loop ends (though
there are enough exceptions to this rule that I don't want the language
to force it on me).

> Secondly, the question of errors.  If the loop variable reaches a state
> from which the postcondition is unreachable, there is an error in the
> code.

Again, who says there has to be a postcondition? The programmer is
thinking about the values i will take on trips through the loop, not
about the value it'll have afterwards.

---Dan

Re: bug me now / bug me later

[David Kassover]

In article <23471:Jun1405:22:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu writes:
>In article <7498@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>> In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:
>> >	a.	for(i = SIZE; i != 0; i -= STEP)
>> >	b.	for(i = SIZE; i > 0; i -= STEP)
>> First, the coding of the loop should have nothing to do with the values
>> of SIZE and STEP.  The code you write should be determined by the
>> postcondition you wish to establish.
>
>Say what? Who cares what the value of i is after the loop?
...
>Again, who says there has to be a postcondition? The programmer is
>thinking about the values i will take on trips through the loop, not
>about the value it'll have afterwards.


That would depend on the loop contents and the programmer, now
wouldn't it?  And in some sense the analyst who wrote the
specification for a task that the programmer chooses to solve
with the loop.

Of course, if one is of the school of thought that a loop must
have only one entrance and only one exit, one has to put in
additional code and a different variable from the loop control
variable to indicate, say, an index into a structure of a
particular feature of that structure.  And possibly waste large
amounts of cycles searching the entire structure for information
that is already found, and possibly will not be found.

Ada has control structures that help with both scenarii (I'm
assuming scenario is from the Italian  8-).

This was crossposted to comp.lang.ada, and comp.lang.c.  Since I
don't read the latter, I have not followed up there.
--
David Kassover             "Proper technique helps protect you against
kassover@ra.crd.ge.com	    sharp weapons and dull judges."
kassover@crd.ge.com			F. Collins