Pointers and Arrays

[Wayne Throop]

> rbj%icst-cmr at smoke.UUCP ((Root Boy) Jim Cottrell)
>> throopw at dg_rtp.UUCP (Wayne Throop)
>>> davidsen at steinmetz.UUCP (Davidsen)

>>> [arguments for allowing (&array)]
>>> Reason 2: "modularity and information hiding"
>> [Still have problem, since current practice is type-anomalous]
> Hopefully, the first element is at the same address as the entire array.

Yes this is often true, and is necessary in C.  But only if you are
looking at "addresses" as typeless entities.  Which they are not, at
least not in C.

>>> Reason 3: "common sense"
>> [Agreed, but make sure that the type is (int (*)[]), not (int *)]
> If you think about it, a pointer to an int can be used (and is) as a pointer
> to an array of ints. Unless you apply ++ to it, they are the same thing.
> (I can already feel the flames approaching).

I assume Jim really means "unless you apply ++, --, [], *, +, -, +=, or
-=" (unless I'm overlooking one).  That is, unless you use it in
arithmetic, subscripting, or indirection.  Sort of covers what you can
do with a pointer, doesn't it?

Remember, a type is not just an interpretation of a pattern of bits.  It
also has to do with what operations are legal on those bits, and what
their effects are.  Thus, just because a pointer to the first int in an
array has the same bit pattern as a pointer to the whole array does NOT
indicate that they are "the same thing", any more than the fact that an
integer zero and a floating point zero often have the same bit pattern
indicates that these are "the same thing".

--
C types require, when pointers pair,
Conversions which are never there.
They aren't there again today,
Please, Dennis, make them go away.
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw