Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!hao!husc6!necntc!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: (*pointer_to_function_returning_int)(args)
Message-ID: <607@haddock.UUCP>
Date: Mon, 22-Jun-87 20:37:38 EDT
Article-I.D.: haddock.607
Posted: Mon Jun 22 20:37:38 1987
Date-Received: Wed, 24-Jun-87 02:54:29 EDT
References: <16673@cca.CCA.COM> <7048@mimsy.UUCP> <786@geac.UUCP> <7088@mimsy.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 34

Declarations: void f(void); void (*pf)(void);

In article <7088@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>I daresay this change [defining pf() and (*pf)(), and hence (****pf)(), to be
>equivalent], considering that it is no change at all to some extant C
>compilers, is safe.

I'm not sure what "safe" is supposed to mean here.  I think the idea is that
it's unlikely that anyone will ever want to use functions (as opposed to
function pointers) as full-fledged objects.  If that's what you mean, I agree
that it will not cause the same sort of problems that arrays have caused (and
structures could have caused, if similar logic had been applied).

My complaint is that, for any object x, it's logically inconsistent to have
"x" automatically mean "&x".  Even if there's no way that "x" alone could have
any meaning in the given context, having the compiler "know" that "&x" was
meant -- and performing the substitution with no warning -- is a botch (in my
opinion!).  (Worse yet, "pf = f" has always been the preferred form, and the
logically correct "pf = &f" elicits a warning!)

As I've said before, I would rather have the standard allow only the forms
"f()" and "(*pf)()", and explicitly bless the syntax "pf = &f".  The "pf = f"
notation (and hence the construct "(*f)()") is too deeply entrenched in
existing code to be removed in this standard, but could be deprecated.  This
would not be a big change (compared to the addition of function prototypes,
say), and the common (but not universal) practice of allowing "pf()" could be
a Common Extension, so nobody gets burned.

I think the most compelling argument is that the equivalence is confusing to
naive users.  (And some sophisticated ones, too, have scratched their heads
for a while upon discovering that "(*****pf)()" was equally valid -- and
decided that it was a quirk of the compiler rather than the language.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint