home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16431 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.1 KB
  1. Xref: sparky comp.lang.c++:16431 comp.std.c++:1585
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!uvaarpa!concert!sas!mozart.unx.sas.com!sasghm
  4. From: sasghm@theseus.unx.sas.com (Gary Merrill)
  5. Subject: Re: something nasty report
  6. Originator: sasghm@theseus.unx.sas.com
  7. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  8. Message-ID: <Bxv8Bq.D7o@unx.sas.com>
  9. Date: Tue, 17 Nov 1992 14:59:50 GMT
  10. References: <1992Nov10.192157.20810@BofA.com> <BxIp1L.M37@unx.sas.com> <5798@npg-sd.SanDiegoCA.NCR.COM> <1992Nov17.013839.20401@microsoft.com>
  11. Nntp-Posting-Host: theseus.unx.sas.com
  12. Organization: SAS Institute Inc.
  13. Lines: 27
  14.  
  15.  
  16. In article <1992Nov17.013839.20401@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
  17.  
  18. |> isn't so who can say?]  Personally, I hate compilers that die without
  19. |> an applicable line#, such that I have to debug by binary chop.  But, I
  20. |> have yet to find any compiler where it is not easy to construct 
  21. |> erroneous input such as to kill the compiler horribly.  A better measure
  22.  
  23. I would dispute the "easy" here (except as a report of your own experience
  24. with a given set of compilers, of course).  It's pretty hard to do this
  25. on our mainframe C compiler.  Usually what is required is some pretty
  26. hideous source that will take advantage of chinks in the compiler's
  27. error recovery and result in a cascade of errors.  Our testing department
  28. is pretty devious and perverse in throwing crap at the compiler.
  29. Still, it's *possible* to construct source that will make the compiler
  30. barf.  We still regard the barfing as a bug.
  31.  
  32. It's been a long time since I used it, but I think the PL/I Checkout
  33. Compiler was pretty robust.  I don't recall ever getting it to go
  34. belly up, but it could get pretty tedious watching it try to reconstruct
  35. an acceptable program from what you had handed it if you just left
  36. a semi-colon off a declaration.  As in virtually everything, there
  37. are tradeoffs here.
  38. -- 
  39. Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
  40. SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
  41. sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
  42.