Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: info for the masses
Message-ID: <14996@smoke.brl.mil>
Date: 27 Jan 91 00:51:46 GMT
References: <7175@crash.cts.com> <14979@smoke.brl.mil> <1991Jan25.233114.17861@ee.ualberta.ca>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <1991Jan25.233114.17861@ee.ualberta.ca> jpenne@ee.ualberta.ca (Jerry Penner) writes:
>Well, can someone who knows all the libraries Orca/C should support
>please inform the rest of us.  I haven't tried to port a lot of stuff
>to orca from unix because I haven't had hardly anytime since November 
>when I got it.  But I'd like to know about these libraries because maybe
>I could write some of them and we'd all be the better for it.

I don't have a complete list at hand, but certainly none of the multibyte
support is present, not that many people in "Western" countries would care.
A more serious lack is vprintf(), vfprintf(), and vsprintf().  Somebody
posted the binary for hos own implementation of the latter to AOL, but I
haven't tested it.  From time to time I encounter other missing standard
functions.  The external name space antipollution requirements of the C
standard are also violated by ORCA/C 1.1; if you are unfortunate in the
choice of names for your external functions or data, you can get an
unpleasant surprise.  <assert.h> also has several deficiencies, such as
not supporting multiple inclusion with differing predefinitions of NDEBUG.

The only way I know of to get a complete list of conformance failures
would be to run a good C test suite (e.g. Plum Hall's); neither I nor
(apparently) ByteWorks feels that we can afford to license such a suite.