Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.sys.apple
Subject: Re: C on the IIGS..
Message-ID: <9897@smoke.BRL.MIL>
Date: 22 Mar 89 04:26:00 GMT
References: <778@orbit.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <778@orbit.UUCP> dougm@pnet51.cts.com (Doug Mcintyre) writes:
>It is full ANSI, and includes most of the libraries ANSI specifies (excluding
>some multi-tasking stuff that wouldn't do a thing on the IIGS).

ANSI C doesn't address multitasking at all.
Perhaps you're thinking about multibyte character sets?
Or even IEEE Std 1003.1-1988?

>Using the toolbox from C involves putting one* thing into the
>compiler. APW C uses the inline() statement which will just push all its
>arguements and then jsl to the place you specify. Thats all a compiler has to
>provide to do any toolbox. All the rest reside in header files, and not even
>in the library (oh and APW C also provides a \p escape to make programming a
>little easier for you..) So adding toolbox support puts a lot of appeal into a
>compiler with adding essentially nothing..

APW C just added one thing, too: the "pascal" qualifier to indicate that
function linkage was to follow Pascal conventions rather than native C.
There is a nice advantage in having the entire linkage done via a header:
The disk storage required for the toolbox support library vanishes.

One would hope that the released version of ORCA/C prefixes their added
keyword(s) with underscores, as required by ANSI C to prevent conflicts
with application names.

Re: multiple memory models: I think this is a mistake.  Could we at
least agree to ignore the small model for anything published in the
newsgroups?  (Publishing source code should suffice.  The problems
mainly arise when linking together object modules/libraries compiled
under different models.)