new Quick C "2" ?

[Brad Brown]

In article <923 at ubu.warwick.UUCP> geoff at emerald.UUCP (Geoff Rimmer) writes:
>
>The problems I have found with QuickC (1.00 and 1.01) are :
>
>...
>(c) my C program is constantly too big for 'link' - when the object
>files are linked together, I frequently get the error "Stack plus data
>exceed 64K".  The only way I have found of getting around this problem
>is to take out several functions in my code (usually functions that I
>*want* in the program, but don't 100% *need* ).  However, soon, it is
>going to come to a point when I am only left with essential functions
>and I am going to have big problems!
>...
>I am using a DELL 200 series 640K RAM, and am compiling in large
>memory model.

The problem you describe is not a bug in the compiler.  You are declaring
large amounts of data as static or declaring many large variables to be
global to a module.  The solution is to make some stuff auto (which doesn't
solve very much because you need to keep the stack size down) or to
dynamically allocate it (which is the smart way to do it.)  The problem
is that all memory models for that compiler need to have global data and
stack in one (64k max) stack.

For instance, you must have some modules that look like this:

--------- Top of file
int bigArray[10000];

void foo()
{
	/*  Do some stuff with bigArray  */
	...
}
---------

which you should change to look like

--------- Top of file
int * bigArray_p;

void foo()
{
	/*  Allocate (zero-initialized) memory for bigArray  */
	bigArray_p = (int *)calloc( 10000, sizeof( int ) );
	if ( bigArray_p == NULL )
		dieHoribleDeath();

	/*  Do some stuff with bigArray  */
	...
}
---------

See, the second way allocates space for bigArray on the heap, where there
is lots of memory, and the linker won't grumble any more.  Besides, doing
things this way will lead to better programming style because it will be
easier to manipulate data and pass it from module to module.

					(-:  Brad Brown  :-)
					bradb at ai.toronto.edu