Path: utzoo!attcan!uunet!mailrus!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: indirect reference/use of procedures
Summary: rambling, might-have-beens.
Message-ID: <16246@haddock.ima.isc.com>
Date: 21 Mar 90 19:06:14 GMT
References: <16702.25FE80FA@urchin.fidonet.org> <A392C67xds13@ficc.uu.net> <1205@sdrc.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 40

In article <1205@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes:
>In article <A392C67xds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
>>[an ANSI function-pointer can be invoked with pf() as well as (*pf)()]
>>What did the committee have in mind when they decided to make this syntax
>>part of the standard?
>
>Would you believe => printf("Hello, world\n"); ?
>
>Since "everyone knows" that you really use the address of a function to call
>it (not the function itself), and since function names usually turn into
>function pointers, it was far simpler to specify that function "objects"
>"always" turn into function pointers and that the function call operator
>requires a function pointer.

There are two ways to state the new rules: (a) Function lvalues decay into
pointer rvalues even when used in a function-call context; the function-call
operator expects a function-pointer operand (usually resulting from such a
decay).  (b) Function lvalues are insulated from such decay when used in a
function-call context; the function-call operator expects its operand to have
function type.  As a special case, a function-pointer used in such a function
context will automatically be dereferenced.

These two variants specify identical syntax and semantics, so they are equally
"correct", although (a) is the one actually used in the ANS.  (b) is the
pre-ANSI specification, except that the last sentence is a Common Extension
rather than a required rule.

My preference would have been to keep system (b), without the special case,
*and* to deprecate the existing rule that function lvalues automatically decay
into pointer rvalues.  Thus, the approved style would be
	pf = &f; /* not "pf = f;" */
	(*pf)();
which would improve the purity of the type system.

I think I did submit this one to X3J11.  They weren't too enthusiastic.  (This
was one of several things that *could* have been "fixed", but only in the long
run, by deprecating what is now a commonly used syntax; the Committee was much
more pessimistic about such things than I.)

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