Path: utzoo!attcan!uunet!snorkelwacker!think!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple
Subject: Re: ORCA/C problems
Message-ID: <12094@smoke.BRL.MIL>
Date: 8 Feb 90 03:46:55 GMT
References: <1990Feb7.034310.5315@ux1.cso.uiuc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <1990Feb7.034310.5315@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes:
>I just got ORCA/C in the mail and am having a problem with it.  The code
>ran fine under APW so I'm thinking it's a compiler bug.  The code in
>question leaves excess values on the stack, evidently, and crashes upon
>return.  Anyone know of any bugs in ORCA that would do this?

The biggest problem in ORCA/C 1.0 is that it generates incorrect code
for accessing static variables.  Consequently you should code like this:
	#define	STATIC	/* define as "static" once ORCA/C bug is fixed */
	STATIC my_array[UMPTEEN];
Of course this means that your STATIC variable names acquire external
linkage, so you have to watch out for conflicts with library globals
and with STATIC and extern data in other application modules.

Also make sure only one of ORCALIB or ORCAGLIB is in the LIBRARIES
folder, depending on the "memory model" you tell the compiler to use
(small model by default, thus ORCALIB).

From reading ORCA/C bulletin boards, it appears that the other biggest
cause of stack corruption etc. occurs when programmers fail to use
proper types for functions.  The recommended practice to reduce this
problem is to ALWAYS #include a header that declares full prototypes
for all functions you might call; that way even if you slip up slightly
the ANSI C argument type coercion will fix the type for you.  In the
absence of a prototype, you'll simply pass the wrong format and/or
amount of data on the stack, resulting in havoc.  The usual culprit
here is a 2-byte integer such as 0 being passed where a function wants
a 4-byte pointer.