Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: Invoking pointers to functions (C sytle)
Message-ID: <2284:Dec1001:01:4690@kramden.acf.nyu.edu>
Date: 10 Dec 90 01:01:46 GMT
References: <1990Dec02.204212.15465@slate.mines.colorado.edu> <989@mwtech.UUCP> <1990Dec08.214057.6280@dirtydog.ima.isc.com>
Organization: IR
Lines: 28

In article <1990Dec08.214057.6280@dirtydog.ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
> Function-call semantics in ANSI C may be described by either of two models
> (here f is a function and pf is a pointer-to-function):

What's common to your two models is that both involve kludges,
expressions decaying from one type into another, etc. Let me describe a
third model that would work perfectly well for C, doesn't require any
hacks in normal situations, and is quite intuitive.

(c) Functions and pointers are logically distinct types. Note that the
name of a function refers to type pointer-to-function, *not* function.
The interesting operations are
	(): pointer -> result-type
	&: function -> pointer, but this is generally redundant (you
	   almost never use functions directly in the first place)
	*: pointer -> function, but this is pointless (you only call
	   functions through pointers, so why use * unless you want to
	   see the actual instructions inside the function?)
As special (deprecated) kludges: Any function in a () context is
converted into the pointer. Any pointer-to-function in a & context is
left alone.

Surely you admit that this is just as clean as your model (b). It has
the advantage of being more realistic---at the machine level you call
functions by address, not by value. And it's a lot closer to common
practice before ANSI. So ANSI could have settled on the above model.

---Dan