Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mit-eddie!ll-xn!ames!umd5!mimsy!aplcen!aplcomm!warper.jhuapl.edu!trn From: trn@warper.jhuapl.edu (Tony Nardo) Newsgroups: comp.sys.amiga.tech Subject: Re: Manx problem with large arrays Keywords: Manx C array help Message-ID: <1138@aplcomm.jhuapl.edu> Date: 11 Jul 88 12:00:32 GMT References: <1795@rtmvax.UUCP> Sender: news@aplcomm.jhuapl.edu Reply-To: trn@warper@aplvax.UUCP (Tony Nardo) Organization: Johns Hopkins University/APL Lines: 59 In article <1795@rtmvax.UUCP> scot@rtmvax.UUCP (Scot Harris ) writes: > >THE PROBLEM: > >Guru visitations when I attempt to set up and use large arrays. Use of the >+D option when compiling does not help. Here is my sample code to >illustrate the problem: > > >/* try.c */ > >main() { static char Map [100000L]; long int i; > >for (i=0; i<100000L; i++) > Map [i] = 'c'; > >puts ("We Did It"); } > >... > >All other applications work fine on my system. The above code runs fine >under 64K and the small data model. What's the problem? > That bug STILL hasn't been fixed?! I've noticed the same problem on 3.4. If you look at the code the assembler generates, you'll see that Aztec C is VERY unhappy about using array sizes larger than 64K. If you try to use more than 64K, it will use some other number (in my case, the low 16 bits of the intended array size) as the array size. However, the code that references the array will generate just fine. Thus, when you access memory beyond the generated boundary, all bets are off as far as where you're writing - other data, other processes, etc. I've had the Guru visit me via this manner. To work around the problem, I've been using a malloc() call to grab the memory I need at the start of the program. This is probably a cleaner use of large memory chunks anyway, since I can give them back to the system when I'm done with them. All the same, I don't like having a compiler FORCE me to be a better programmer... Tony P.S. MANX, if you're out there - I received V3.4 last winter, mailed in the registration card, but STILL haven't heard anything about upgrading to V3.6... ============================================================================== ARPA: trn@warper@aplvax.jhuapl.edu \ one of these should work, aplcen!isl!trn@aplvax.jhuapl.edu } but you may have to route nardo%str.decnet@capsrv.jhuapl.edu / thru ucbvax.berkeley.edu UUCP: aplcen!aplvax!trn@warper USnail: c/o Johns Hopkins University/APL, Room 7-53 Johns Hopkins Road Laurel, Md. 20707 "bug , n. ... 4. [Sl.] undocumented software feature" ==============================================================================