Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!ll-xn!cit-vax!nike!think!ima!haddock!karl
From: karl@haddock
Newsgroups: net.lang.c
Subject: Re: Pointers and Arrays
Message-ID: <86900016@haddock>
Date: Fri, 15-Aug-86 19:40:00 EDT
Article-I.D.: haddock.86900016
Posted: Fri Aug 15 19:40:00 1986
Date-Received: Sun, 17-Aug-86 07:28:06 EDT
References: <513@hadron.UUCP>
Lines: 19
Nf-ID: #R:hadron.UUCP:513:haddock:86900016:000:1087
Nf-From: haddock!karl    Aug 15 19:40:00 1986


dg_rtp!throopw (Wayne Throop) writes:
>What I was objecting to was elevating this common bug [interpreting &a as
>&a[0]] to a "standard feature".  I still think it would be wrong to do so.
>If it means anything (and currently it does *NOT*), (&array) should indicate
>the address of the whole array, not the address of its first element.

As I mentioned before, X3J11 seems to have accepted the "correct" meaning.
In the case of the other "optional ampersand", if f is a function locator,
then "&f" and "f" are equivalent.  I personally think the first is more
meaningful (language purity and all that; "f" should denote the function as a
whole, even if you can't do anything with it other than "&" or "()"), but I
don't use it because lint prefers the second.  I also detest the usage of
"pf()" for "(*pf)()", but X3J11 has blessed this as well.  (In fact, they
defined "()" to *always* operate on a function *pointer* (possibly obtained
from the implied "&" on a function locator), so now the first form is more
"correct"!)

Karl W. Z. Heuer (ihnp4!ima!haddock!karl), The Walking Lint