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