Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!prism!loligo!pepke
From: pepke@loligo.cc.fsu.edu (Eric Pepke)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C Array Design Flaw
Message-ID: <696@loligo.cc.fsu.edu>
Date: 7 May 89 04:35:10 GMT
References: <664@loligo.cc.fsu.edu> <24093@agate.BERKELEY.EDU>
Reply-To: pepke@loligo.UUCP (Eric Pepke)
Organization: Florida State University, but I don't speak for them.
Lines: 24

In article <24093@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes:
>The code generated for Access7 looks correct to me.  The key point is
>that the MULS.W instruction produces a long result.  Since the code
>needs to multiply a, a *signed* word, by 14, MULS.W is the most
>straightforward way to get the right result.  Problems with 32K will
>only arise if a>=32K (which it can't be) or if the row size>=32K, in
>which case I presume (or at least hope) different code is generated.

The same code is produced if I define access7 as

short Access7(array, a, b)
short array[][7];

This is perfectly legal C, and it makes no assumptions on how big the
array is.  If you have enough memory, a call to Access7(40000, 2) should
be perfectly reasonable, but it will fail. 

Eric Pepke                                     ARPA:   pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute  MFENET: pepke@fsu
Florida State University                       SPAN:   pepke@scri
Tallahassee, FL 32306-4052                     BITNET: pepke@fsu
 
Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.