Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: orca/c bugs
Message-ID: <1991Jan31.081323.26727@nntp-server.caltech.edu>
Date: 31 Jan 91 08:13:23 GMT
References: <2092@kluge.fiu.edu>
Organization: California Institute of Technology, Pasadena
Lines: 64

acmfiu@serss0.fiu.edu (ACMFIU) writes:

>1.	#pragma debug 25
>2.	#pragma optimize -1
>3.	prototype all functions

#pragma lint -1

will tell you if you're passing the wrong size parameters, if you prototype
your functions (a good idea in any case).

>5.	NULL == 0

Perhaps this fails because NULL is a long equaling zero and 0 is an int
equaling zero. I've noticed that Orca/C fails to do implicit type-conversion
in certain cases, and adding L's or (long)'s always fixes the problem.

>6.	inline asm

Always works like a charm for me, with one exception: the mini-assembler
always puts 16 bit immediates in the generated code -- it appears to
only change the immediate operand size after the close bracket of the asm{}
and then it uses 8 bit immediates for the rest of the source file! Since I
was forgetting to restore the register sizes anyway, fixing my bug circumvented
Orca's.

>7.	static variables

I'm surprised you can put up with 1000 line source files -- I start splitting
mine up if they're going to be more than a couple hundred lines. Orca's support
for multiple object files is excellent and it's been there since the original
Orca/M for the ][+.

>9.	array indexing
>		foo[strlen (foo) - 2] = '/'

try 2L and see what happens.

>10.	a = (1 == 1 ? 1 : 2)

I tried the above expression with nothing else around it and it compiles fine.
Try sprinkling parenthesis on the off chance that the order of operators is
off; if a is a long then L's are probably a good idea also.

>11.	out of memory

Haven't had that problem yet, most likely because none of my source files
is longer than 500 lines. I highly recommend organizing your project in small
chunks of related subroutines, it works great -- example:
	ga.c	(top level code)
	lhg.c	(Lord High Giffer GIF file parser)
	rblk.c	(GIF raster decompression -- no longer used)
	rblk.asm (GIF raster decompression, call w/ same prototype as rblk.c)
	di.c	(color crunching and picture display)
	gsio.c	(GS/OS operations; Nice C functions to hide the pBlock stuff)
None are over 350 lines. Since I am usually doing intensive work on only one
of these files at a time, I save at lot of time in recompiles. I don't like
using the specific subroutine compile.

Todd Whitesel
toddpw @ tybalt.caltech.edu

P.S. LHG is going to undergo a major rewrite -- whether that happens before or
after I release the demo version is still unknown at this point.