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.