home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16442 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  3.1 KB
  1. Path: sparky!uunet!know!hri.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!swrinde!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hplextra!hpcss01!hpcupt1!jamiller
  2. From: jamiller@hpcupt1.cup.hp.com (Jim Miller)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Help - What Is Wrong?
  5. Message-ID: <138740001@hpcupt1.cup.hp.com>
  6. Date: 13 Nov 92 00:36:58 GMT
  7. References: <720002131.AA03045@csource.oz.au>
  8. Organization: Hewlett Packard, Cupertino
  9. Lines: 61
  10.  
  11. >comp.lang.c / mjs@hubcap.clemson.edu (M. J. Saltzman) 
  12. >
  13. >Presumably, "i != 5" is "less safe" because a failure of the initial
  14. >condition to satisfy i < 5 will not result in an infinite loop
  15. >(especially if the initializer "i = 0" is replaced by, say, "i = j + 1",
  16. >or if the initial i is passed as a parameter).  On the other hand,
  17. >this may not be the best kind of "safety" to have.
  18. >
  19. >In _The_Science_of_Programming_[1], David Gries argues that the guards
  20. >on loops should be as weak as possible, so that if the initial
  21. >condition is violated, the program will fail catastrophically (i.e.
  22. >with an infinite loop).  
  23.  
  24. IMHO: yes and no.
  25.  
  26. While unit testing, "i != 5" might be the better idea for the reasons stated,
  27. for *production* I'd choose "i < 5".  If the program can continue to limp
  28. along instead of crash/hang, the user may still be able to use it,
  29. they may be able to save their data, they may even be able to survive.
  30.  
  31. I agree that for OS code the policy of "if anything is wrong: DIE
  32. immediately" is the best policy, but I don't like applications that do that.
  33.  
  34. Just *why* do you want the user to have an application that hangs when the
  35. task presently being performed might be a minor one?
  36.  
  37. The risk to user data will be, in general, no worse for continuing
  38. than for aborting/hanging immediately.  (This is based upon absolutely
  39. no data what so ever :-).
  40.  
  41. I usually have a backup of my old data, it's my work of the last 2 hours
  42. that I want a *chance* to save.
  43.  
  44. An immediate halt/hang *will* cause loss of all currently changed data.
  45. In the middle of many change operations, it *will* cause the data to
  46. be useless.
  47.  
  48. Continuing may, or may not, cause loss of data.  Immediate halt/hang will,
  49. however, should prevent any data from getting back to the disk (or other
  50. device), which is why for OS code it may be the best policy (I don't want
  51. my directories corrupted :-().
  52.  
  53. Think of real life: do you want your car to halt in the middle of nowhere
  54. because the oil is low, or do you want it to tell you (using an idiot
  55. light) that something is bad and let you take the corrective action?  
  56.  
  57. Note: in critical situations the argument changes.  While inserting
  58. control rods in a nuclear reactor, I want the program to continue,
  59. while removing control rods I want it to hang or abort -- except that
  60. I do NOT want it to loop forever on "remove control rod i, i+1, i+2, etc".
  61.  
  62. Ok, David Gries and I disagree. 
  63. So, an  expert  and I disagree.
  64. So, what else is new?  :-)
  65.  
  66.  
  67.    jim miller
  68.    jamiller@cup.hp.com
  69.    (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
  70.    Anything I say will be used against me ...
  71.    But my company doesn't know or approve or condone anything of mine here.
  72.