From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,df854b5838c3e14
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,df854b5838c3e14
X-Google-Attributes: gid103376,public
X-Google-Thread: 1014db,df854b5838c3e14
X-Google-Attributes: gid1014db,public
X-Google-Thread: 10db24,fec75f150a0d78f5
X-Google-Attributes: gid10db24,public
From: miker3@ix.netcom.com (Mike Rubenstein)
Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
Date: 1996/04/21
Message-ID: <317a3715.38162294@nntp.ix.netcom.com>#1/1
X-Deja-AN: 150649013
references: <4kk9e1$he1@nntp.Stanford.EDU> <dewar.829276268@schonberg>
 <01bb2ed2.425fb900$65c2b7c7@Zany.localhost>
organization: Netcom
x-netcom-date: Sun Apr 21  8:35:54 AM CDT 1996
newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
Date: 1996-04-21T08:35:54-05:00
List-Id: <comp.lang.ada>

Bradd W. Szonye <bradds@ix.netcom.com> wrote:

> Try to keep in mind the spirit of defensive programming:
> If there's something ambiguous about the way you could implement
> something, and one implementation is safe regardless of how you interpret
> the ambiguity, the other implementation only works under one specific
> interpretation, then defensive programming (and portable programming) will
> encourage the code that works under all circumstances. Consider:
> 
> for (size_t i = 0; i < 10; i++) do_stuff();
> 
> versus
> 
> for (size_t i = 0; i != 10; i++) do_stuff();
> 
> Even though you *know* that i will never be greater than 10, even though
> "not equals" should always stop the loop after the tenth iteration,
> practically every programmer will write the first loop in preference to
> the second. This has nothing to do with standards; the standards say that
> i is a local, stack-based variable, not global, and since it is not
> volatile or referenced by anything else, do_stuff() couldn't modify it,
> even another thread couldn't modify it. But should your memory chips fail,
> or do_stuff() accidentally trash the stack with a pointer, then the first
> loop will never let i get out of the range of 0 <= i < 10, while the
> second loop might.

What nonsense.  Most programmers write the loop the first way out of
habit and for consistency.  Suppose we change the loop a little:

	for (size_t i = a; i < 10; i++) do_stuff();
 
versus
 
	for (size_t i = a; i != 10; i++) do_stuff();

Now the loops mean different things.  Either might be correct, but the
first is by far the more common.

If the stack is trashed or the memory chips have failed, why do you
want to get out of the loop?  Why do you assume that getting out of
the loop prematurely is better than not getting out of it at all?
Suppose the loop is part of a sort.  If you stay in it, the program
will hang and the user will complain.  If you exit it the program may
continue and output erroneous information that causes costly errors.

Defensive programming is important, but coding so you'll exit a loop
even if the hardware fails has nothing to do with it.


Michael M Rubenstein