knudsen@ihwpt.UUCP (mike knudsen) (03/21/86)
Thanks to those who have responded to my question about mysterious C.link errors. Some say it is due to Pass2 running out of disk space, others to Pass1 running out of RAM. Both may be correct; on my flakey Coco, I can sometimes get a bogus "out of storage" error from Pass1. I say bogus because it happens on a file that never had the problem before. However, it beats the more common spontaneous re-boots as noted in another posting. Sooner or later I get lucky and get a REAL compile. As for disk space, sometimes disk writes abort early and leave a truncated version of the file, which would certainly look to the Assembler like Pass2 ran out of disk space. BTW, your RAM space during Pass1 gets eaten up by any global or static variables in your file (unless extern). So big arrays or structures should not be put with large source files. Really big arrays would have to be faked with alloc() and malloc(), I guess. Anybody out there ever try those and live? mike k
michael@python.UUCP (M. Cain) (03/24/86)
> Really big arrays would have to be faked > with alloc() and malloc(), I guess. Anybody out there > ever try those and live? > > mike k I have an editor that uses one of alloc() or malloc() -- I don't remember which off the top of my head -- to get buffer space as needed. My reason was that I occasionally run my Coco multi-user, with my wife and I both editing small files, and wanted the buffer size to be "just big enough" to hold the file. The buffer is in memory rather than on disk because both the console and the external terminal are dead while the disk is running. I've been contemplating a RAMdisk to alleviate the limited buffer size problem inherent in my current solution. Michael Cain