[comp.lang.c] Compiler-heap woes....

billf@hpcvlx.cv.hp.com (Bill F. Faus) (12/27/89)

Caveat: novice C hacker at work.

I am attempting to compile in a lot of literal text and hex info
into a Microsoft 5.1 C program.  The compiler seems to choke after
about 40K of literal info:

    char *ptr[] = {"string-1", "string-2", ..., "string-1000"};

with each string about 40 chars long.  I get error "C1002: out
of heap space".  Am I stupid, or is the compiler so weenie it can't
handle more than 40K of literal numbers and strings?  How do I give
the compiler more heap space?

So far I've wasted 3 days breaking my literal definitions into
separate code segments, compiling each piece, and linking the
stuff all back together.  It looks really crummy compared to
the bigger UNIX systems I'm used to. 

"Short of time and brains and desperate for help"

---------------
billf@cv.hp.com 

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (12/28/89)

In article <101850003@hpcvlx.cv.hp.com> billf@hpcvlx.cv.hp.com (Bill F. Faus) writes:
>I am attempting to compile in a lot of literal text and hex info
>into a Microsoft 5.1 C program.  The compiler seems to choke after
>about 40K of literal info:
>
>    char *ptr[] = {"string-1", "string-2", ..., "string-1000"};
>

I'm in the wrong building to double check the books, but, since Intel segmented
architecture severely limits any structure to 64K, and MSC5.1 is probably trying
to put all your strings in one segment, plus other runtime string literals, and
your stack...

MSC memory model looks something like this...

                ----------------- 
                |  code         | segments 1..n
                -----------------
                |  data         |  \
                -----------------   \
                |  near heap    |    } 1 segment on small (default) model
                -----------------   /
                |  stack        |  /
                -----------------
                |  far heap     |
                -----------------

Only work around that I know of is to use the large memory model, compile all
your string literals in a separate module, declare them extern in all the other
modules, and let the linker do its' thing...

Or try whichever of the mid-sized memory models that allows unlimited data, I
can never remember whether it's compact or medium;  you'll still want to 
have the strings in a separate module and link it.
Chewey, get us outta here!
                 
kaleb@mars.jpl.nasa.gov             (818)354-8771
Kaleb Keithley

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/28/89)

  Let me throw out a few ideas here, because I'm not sure which one will
be useful. First, I wasn't clear if the message came at compile or load
time. If it came at compile time the option -LARGE will often help.
Before going to the {whatever} model for compilation, try some of: (a)
playing with the stack/heap ration with the -F command, (b) making that
one array 'far' or even 'huge', (c) diddling with the size of the data
item which get their own segment (only if it happens at link time), or
(d) combinations of the above.

  Hope some of this is useful, I offer one additional suggestion, which
I used to solve a similar problem: (e) get a 386 and stop worrying
about running into all the stupid limits. I spent three years with a
286 at work, but at home went directly from CP/M to 386 UNIX without a
stop at the 286. I highly commend it.

-- 
	bill davidsen - sysop *IX BBS and Public Access UNIX
davidsen@sixhub.uucp		...!uunet!crdgw1!sixhub!davidsen

"Getting old is bad, but it beats the hell out of the alternative" -anon

billf@hpcvlx.cv.hp.com (Bill F. Faus) (12/30/89)

Well...thanks for the tips.

I called MicroSoft directly (Corvallis is just a stone's throw
from Seattle), and they said, essentially...oh yeah...too bad.

The heap of the compiler (not the running program) is being
overloaded.  There are three compiler heap messages:

C1002 -- out of heap space

C1059 -- out of near heap space

C1060 -- out of far heap sapce

I was getting the first of these.  The README.DOC file mentions
option /B1 <path>\C1L.EXE to call the large compiler.  I tried
this and it didn't help.  The README.DOC file says this option
will help if you are getting message C1059.

What did eventually work, was the sleazy workaround of breaking up
my initialization statements into 5 (yes F-I-V-E) separate code
fragments, and making sure variable names were cross-referenced
between the fragments.

Requirements from 'on high' dictated that all data be compiled
into the program, and that it run on as many 8086 machines
and monitors as possible.

I compiled the fragments that were doing the variable intialization
with:  cl /c /AC /Gt 1.  Which tells the compiler to use the compact
model (one code segment, many data segments), and put all data over
one byte into far segments.  

---------------
billf@cv.hp.com