Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: pointers to functions
Message-ID: <11015@smoke.BRL.MIL>
Date: 9 Sep 89 13:46:57 GMT
References: <1679@hydra.gatech.EDU> <9429@chinet.chi.il.us> <22005@cup.portal.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <22005@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
>	(***************f)();
>This will also invoke the function on most compilers.  Tell me with a
>straight face that this is not a bug.  Does ANSI require this to work?

Yes.  It's a side effect of the fact that a function is actually called
via a pointer to it.  Since people write sin(x) instead of (*sin)(x),
the Standard had to adopt the rule that the name of a function gets
turned into a pointer to the function in such a context.

>> If f holds the address of the start of the function, *f really doesn't
>> have any meaning.  
>It certainly does.  *f means the function that starts at f.

What could you do with it, other than immediately & it again?
It's not an object in data space, so you can't do things like
store it into a variable or inspect its contents.

Functions are rather like arrays, in that they're not first-class
things in C.  The Standard now allows &array to generate a pointer
to array, but couldn't go all the way and allow array variables etc.
Similarly, C already had a certain degree of confusion about functions
themselves vs. pointers to them.  X3J11 came up with rules that
covered the expected behavior (as well as lead to surprising anomalies
such as the one you mentioned).