Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ucsdhub!hp-sdd!hp-pcd!hpcvlx!billf
From: billf@hpcvlx.cv.hp.com (Bill F. Faus)
Newsgroups: comp.lang.c
Subject: Re: Compiler-heap woes....
Message-ID: <101850004@hpcvlx.cv.hp.com>
Date: 29 Dec 89 23:39:52 GMT
References: <101850003@hpcvlx.cv.hp.com>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 35

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