Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!spdcc!ima!dirtydog!karl
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Invoking pointers to functions (C sytle)
Message-ID: <1990Dec12.055616.17732@dirtydog.ima.isc.com>
Date: 12 Dec 90 05:56:16 GMT
References: <1990Dec02.204212.15465@slate.mines.colorado.edu> <989@mwtech.UUCP> <1990Dec08.214057.6280@dirtydog.ima.isc.com> <2284:Dec1001:01:4690@kramden.acf.nyu.edu>
Sender: news@dirtydog.ima.isc.com (NEWS ADMIN)
Reply-To: karl@ima.isc.com (Karl Heuer)
Organization: Interactive Systems
Lines: 21

In article <2284:Dec1001:01:4690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>What's common to your two models is that both involve kludges,

I don't think that's avoidable, given the semantics.

>(c) Functions and pointers are logically distinct types. Note that the
>name of a function refers to type pointer-to-function, *not* function.
>...Any pointer-to-function in a & context is left alone.

Doesn't work.  You need to have `&f' yield pointer-to-function, while `&pf'
yields pointer-to-pointer-to-function.  Thus, `f' and `pf' must have different
types in an lvalue context.

>It has the advantage of being more realistic---at the machine level you call
>functions by address, not by value.

If we were to continue in that vein, I'd also have to say that the left
operand of the assignment operator should logically be a pointer instead of an
lvalue.  That way lies BLISS.

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