Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!styx!ames!ucbcad!ucbvax!decvax!mcnc!rti-sel!dg_rtp!throopw
From: throopw@dg_rtp.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: pointers to arrays
Message-ID: <714@dg_rtp.UUCP>
Date: Tue, 25-Nov-86 17:27:56 EST
Article-I.D.: dg_rtp.714
Posted: Tue Nov 25 17:27:56 1986
Date-Received: Wed, 26-Nov-86 19:58:12 EST
References: <273@bms-at.UUCP> <1138@genrad.UUCP> <274@bms-at.UUCP>
Lines: 70
Summary: Stuart musta missed Mark Braders message, key points reviewed.

>,>>> stuart@bms-at.UUCP (Stuart D. Gathman)
>> rep@genrad.UUCP (Pete Peterson) writes:

I suspect that Stuart missed Mark Brader's excelent review of pointers
to arrays, posted here a while back.  I'll expand on some of the points
Stuart raises here, but sadly I think Stuart's example can't be coded
much "better" than he in fact codes it (at least, not in pre-X3J11 C).

>>>1) How does one get such an animal?  The only methods I can figure are
>>>     a) a cast: ( type (*)[] ) array_of_type
>>>     b) a function returning such a type (but the return must use a cast!)
>> [ example of pointer to array declaration deleted ]
>         I am quite aware of how to *declare* pointers to arrays (as a
>         cursory perusal of my posting will reveal).  I want to know how
>         to get a pointer to an array in an expression!  The key problem
>         is that arrays are always converted to pointers to their first
>         elements.

Wrongo.  Arrays are *NOT* always converted into pointers to their first
elements.  One case is old and obvious: (sizeof(arrayname)).  Another
case (actually, a set of cases including this one) is newly proposed by
X3J11: (&arrayname).  Further, the fact that arrays are often converted
to pointers to their first element does not in any way make it difficult
to get a pointer to an array in an expression (in fact, this is
trivial).  Here is a code fragment that illustrates passing a pointer of
type (int (*)[N]) to a function 'f':

        { int a[M][N];     f( a ); }

>         Given a pointer to the first element, I can increment it by the
>         number of elements in the array.  Having a pointer to an array
>         conveniently remembers the number of elements for me (this would
>         be especially handy with dynamically sized arrays a la algol).
>         But, the aggravation of having to use casts to get such a pointer
>         into an expression defeats the purpose!

Maybe.  But where did you get the strange idea that you have to use a
cast to get such a pointer?  Inside the function 'f' from above, we
might have:

        f(a) int (*a)[N]; {
            int (*orig_a)[N]) = a;
            for( ; (a-orig_a)<M; ++a )
                ...
        }

which will step the pointer a along the M arrays that make up the actual
two-dimensional array.  (Note that this isn't what Stuart wanted, as we
find out below, but it does satisfy what he said above.)

> [example using jmp_buf, mostly deleted]
>   envptr = &local_env;  /* oops! illegal! */

Note that it won't be illegal if/when X3J11 is adopted.  This will then
be the "best" way of doing what you wanted to do.

> IS THERE A BETTER WAY ? [than wrapping a struct around the arrays]

Well, the struct kludge seems like a pretty good way to me, given C's
current limitations.  I doubt there is a "better" way, barring waiting
for X3J11 compliant compilers.  Of course, you still can't recursively
typedef, so casts or the struct kludge will still be needed in some
cases.  Sigh.

--
A programming language is low level when its programs require attention
to the irrelevant.
                                --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw