Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!helios.ee.lbl.gov!ux3.lbl.gov!beard
From: beard@ux3.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C Array Design Flaw
Message-ID: <2595@helios.ee.lbl.gov>
Date: 10 May 89 18:10:43 GMT
References: <664@loligo.cc.fsu.edu> <24093@agate.BERKELEY.EDU> <696@loligo.cc.fsu.edu> <698@loligo.cc.fsu.edu>
Sender: usenet@helios.ee.lbl.gov
Reply-To: beard@ux3.lbl.gov (Patrick C Beard)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 53

In article <698@loligo.cc.fsu.edu> pepke@loligo.UUCP (Eric Pepke) writes:
>In article <696@loligo.cc.fsu.edu> I write:
>>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. 
>
>This statement of mine is nonsense, of course.Such a call is only reasonable 
>in a C where int is defined as bigger than 16 bits.  When you use Lightspeed
>C, as you would have to declare a and b as long integers.  When you do that, 
>you get what looks like correct code.  
>
>Also, my statement that Lightspeed C would generate bad code in some cases
>where a syntax check would fail is also wrong.  The multiplier for the first
>subscript is determined by dimensions 2 through N, and cases where the
>multiplier would be greater than 32767 would be rejected first by the
>test for arrays with size greater than 32767.
>
>What is will do is reject certain array declarations needlessly, as in the
>case of hist[32][32][32];
>
>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.

I'm sorry, but I just couldn't let this discussion go by without making
a comment.  The problem you are discussing, passing static or automatic arrays,
such as foo[40][50] to subroutines with a declaration such as foo[][50] is
doomed to fail not because of a failing in THINK C (formerly LightSpeed C),
but because of an inherent flaw (feature?) in the C programming language.
Namely, the duality between arrays and pointers makes passing arrays of
dimension >= 2 impossible.  The reason is that the compiler assumes that
a declaration of foo[][50] really means *foo[50], an array of pointers.
The array foo[40][50] is really just one long chunk of memory, and an
index into it, such as foo[y][x] is really just foo+40*y+x.  The called
subroutine has no knowledge of the inner dimensions of the array, and so.
has to resort to foo[y][x] meaning *(*(foo+y)+x), or *(foo[y]+x).

The solution to all of this, is to always pass around arrays of pointers,
not true two-dimensional arrays.  Then you can have arrays of dimensions
of as large as you like.

I hope this sheds some light on this discussion.

__________________

   Patrick Beard
  PCBeard@lbl.gov
 BSI, Berkeley, CA
___________________