home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16419 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.9 KB
  1. Xref: sparky comp.lang.c++:16419 comp.std.c++:1583
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!microsoft!hexnut!jimad
  4. From: jimad@microsoft.com (Jim Adcock)
  5. Subject: Re: something nasty report
  6. Message-ID: <1992Nov17.013839.20401@microsoft.com>
  7. Date: 17 Nov 92 01:38:39 GMT
  8. Organization: Microsoft Corporation
  9. References: <1992Nov10.192157.20810@BofA.com> <BxIp1L.M37@unx.sas.com> <5798@npg-sd.SanDiegoCA.NCR.COM>
  10. Lines: 26
  11.  
  12. In article <5798@npg-sd.SanDiegoCA.NCR.COM> rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
  13. |In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
  14. |
  15. |>When a compiler dies with an internal error, causes an access
  16. |>violation, etc. it is *always* a bug.
  17. |
  18. |Not *always*: if the internal error is caused by an error in the program
  19. |being compiled, it is merely a very user-unfriendly error message (I
  20. |consider "segmentation violation -- core dumped" to be the ultimate
  21. |diagnostic).
  22.  
  23. I'd say you're both right -- because a "bug" is any failure to meet
  24. customer expectations.  In the case of the "C" standard it is quite
  25. "legal" for a compiler to crash when fed an erroneous program --
  26. as long as it emits some kind of warning or error message before during
  27. or after its death.  Whether or not this meets customer expectations
  28. or not is not a "legal" issue.  [In the case of the "C++" standard there
  29. isn't so who can say?]  Personally, I hate compilers that die without
  30. an applicable line#, such that I have to debug by binary chop.  But, I
  31. have yet to find any compiler where it is not easy to construct 
  32. erroneous input such as to kill the compiler horribly.  A better measure
  33. is whether or not beginning programmers frequently write erroneous programs
  34. that invoke such horrible deaths.  Once people begin to understand the language,
  35. they tend to exercise these truly exceptional paths [partway;-] through 
  36. the compiler less often.
  37.  
  38.