Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.sys.apple Subject: Re: Orca/C V1.0 bugs Message-ID: <11207@smoke.BRL.MIL> Date: 2 Oct 89 18:08:23 GMT References: <8910020336.AA13294@trout.nosc.mil> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 31 In article <8910020336.AA13294@trout.nosc.mil> mmunz@pro-beagle.cts.com (Mark Munz) writes: > Did you expect it to be completely BUG FREE? Come on. I hope not. Any > large program will have all kinds of bugs that will never be found in > beta testing (no matter how long it is). The fellow's point was probably that it would have been impossible to miss most of the reported bugs with even a minimal attempt to apply the compiler to existing production code. The ones I reported all turned up quite soon during an attempt to port an application that had been carefully designed for portability and during initial straightforward implementation of a program in portable C to simply read in OMF files and display the contents of their segment headers. > I'm sure that languages are even more difficult to test. All the different > combinations that a language can have. Being a programmer, I've seen this > happen (where beta testing doesn't catch all). C isn't particularly hard to test; there are numerous test suites commercially available. ByteWorks may have felt that they couldn't afford any of them. I'm pretty sure that ORCA/C V1.0 couldn't possibly have passed the Plum Hall Standard C validation suite. > As for comparing Orca/C and gnu C, you forgot to mention that gnu C isn't > available on the IIGS. That is a valid rebuttal. Who cares how good and cheap a product is if it doesn't meet our needs? I assume ByteWorks is working on an improved release of ORCA/C. It would be nice to be able to quit worrying about the compiler and get back to worrying about our programs.