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: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: thp@cs.ucr.edu (Tom Payne) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/22 Message-ID: <4lgaeq$l1g@galaxy.ucr.edu>#1/1 X-Deja-AN: 150816125 references: <4kk9e1$he1@nntp.Stanford.EDU> <01bb2ed2.425fb900$65c2b7c7@Zany.localhost> <317a3715.38162294@nntp.ix.netcom.com> followup-to: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu organization: University of California, Riverside newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-22T00:00:00+00:00 List-Id: Mike Rubenstein (miker3@ix.netcom.com) wrote: : Bradd W. Szonye 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. [...] : Defensive programming is important, but coding so you'll exit a loop : even if the hardware fails has nothing to do with it. I'm not sure that I agree with the fundamental premise behind defensive programming: "Don't make your program a sucker for bugs." [p. 45, Software Tools, Kernighan and Plauger] Granted, if its an embedded controller in a life-support system, I'd like every routine to make every effort to muddle through even in the presence of bizarre hardware faults, etc. In general programs, however, I'd like them to crash as soon as possible when something is wrong, and for that reason I've gone back to the i != 10 style for upper limits on for-loops. Tom Payne (thp@cs.ucr.edu)