home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16410 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.5 KB
  1. Xref: sparky comp.lang.c++:16410 comp.std.c++:1581
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!concert!gatech!hubcap!ncrcae!ncr-sd!npg-sd!rns
  3. From: rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: something nasty report
  6. Message-ID: <5799@npg-sd.SanDiegoCA.NCR.COM>
  7. Date: 16 Nov 92 20:31:30 GMT
  8. References: <1992Nov10.192157.20810@BofA.com> <BxIp1L.M37@unx.sas.com> <5798@npg-sd.SanDiegoCA.NCR.COM> <1992Nov14.233744.27337@ornl.gov>
  9. Organization: NCR Corp., Network Products - San Diego
  10. Lines: 42
  11.  
  12. In <1992Nov14.233744.27337@ornl.gov> mullens@jamsun.ic.ornl.gov (James A. Mullens) writes:
  13.  
  14. >In article <5798@npg-sd.SanDiegoCA.NCR.COM>, rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
  15. >|> In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
  16. >|> 
  17. >|> >When a compiler dies with an internal error, causes an access
  18. >|> >violation, etc. it is *always* a bug.
  19. >|> 
  20. >|> Not *always*: if the internal error is caused by an error in the program
  21. >|> being compiled, it is merely a very user-unfriendly error message (I
  22. >|> consider "segmentation violation -- core dumped" to be the ultimate
  23. >|> diagnostic).
  24.  
  25. >You forgot the (;-), right?
  26.  
  27. I purposely omitted it, but it was implied.  I try to be subtle.
  28.  
  29. Sorry to decrease the signal/noise ratio of comp.std.c++, though.  I had
  30. second thoughts after posting (although the original article, and resulting
  31. thread, shouldn't have been cross-posted to comp.std.c++, anyway).
  32.  
  33. >I'd say *always*.  I'd also say that C++ compilers are more prone to this
  34. >problem than any other language compilers (my experience anyway).
  35.  
  36. cfront seems to be prone to this.  Are these other C++ compilers cfront-based?
  37. [You don't have to answer that.]
  38.  
  39. >When I'm faced with an access violation/segmentation violation/bus error,
  40. >and I really have no clue as to what's causing it, I start removing large
  41. >blocks of source code with #if 0 ... #endif until the compiler finishes
  42. >successfully.  Then I reintroduce parts of code until the compiler bombs
  43. >again.  In the end, the problem is isolated.  I may have a programming
  44. >error there, or the compiler may just be batty.  I always send a bug report.
  45. >I'd like to send a bill for my time ( at $60/hour :-).
  46.  
  47. It's always a good idea to try to isolate a problem before reporting it:
  48. it increases your chances of having the bug fixed (not to mention helping
  49. out the people supporting the software).
  50.  
  51. Follow-ups probably not appropriate, but I'm not redirecting them.
  52.  
  53. -- Rick Schubert (rick.schubert@SanDiegoCA.NCR.COM)
  54.