Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!diku!aggaton From: aggaton@diku.dk (Klavs Torben Pedersen) Newsgroups: comp.sys.amiga.programmer Subject: Is There a bug in Lattice C? Summary: Far addressing in Lattice C Message-ID: <1991Feb26.003522.29791@odin.diku.dk> Date: 26 Feb 91 00:35:22 GMT Sender: news@odin.diku.dk (Netnews System) Organization: Department of Computer Science, U of Copenhagen Lines: 30 (Sorry For reposting this article, but I didn't know until now where to) (post it :)) Hi! I've been sitting for a long time trying to figure out, if it's me who are using far addressing in the wrong way, or there is a bug... As stressed several times in the manual I use the new keywords far and chip on every global variable instead using -abcd and -b0 on the option-line. This goes fine. After that I link without SmallData option using upstart module c.o and library lcm.lib, lc.lib and amiga.lib. But suddenly the linker drops out telling me, that there is a reference to an unmerged item??? But I didn't want to merge it...The linker is not supposed to just creating simple 16bit addressing (Which is far too little when working with graphics). (I've also tried to mess a bit with NOALVS, without succes.) After this depressing situation I jumped to the ultimate solution and compiled every module with -b0 (took 2 hours). Still no problem except for a 40k larger program. And it links fine??? Should the new far and chip keyword not work the same way as -b0? Should I use -ck? Now to the funny part. Before I ran the program I checked the available memory, and after exiting there is missing 'bout 3k using the -b0 program??? All I've done is adding some chip data to the old program, which exits nicely??! !! Am I doing something wrong? or is it a bug? Klavs Pedersen aggaton@freja.diku.dk P.S. I'm using Lattice C 5.10 from SAS institute. --