Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!botter!star.cs.vu.nl!maart
From: maart@cs.vu.nl (Maarten Litmaath)
Newsgroups: comp.lang.c
Subject: function pointers and misbehavior
Message-ID: <3215@solo3.cs.vu.nl>
Date: 11 Sep 89 15:35:03 GMT
References: <1989Sep8.021802.29203@Octopus.COM> <794@sdrc.UUCP>
Organization: V.U. Informatica, Amsterdam, the Netherlands
Lines: 38

scjones@sdrc.UUCP (Larry Jones) writes:
\... Once again, let's all repeat in unison:
\In C, the use of a variable and it's declaration should look the
\same.

IMHO dmr should have handled function pointers as follows:

	int	i, foo(), (*bar)();

	/*
	 * `foo' is the function (i.e. the code),
	 * foo() is its result (return value),
	 * &foo is its address (i.e. address of its label),
	 * `bar' is a pointer to a function (i.e. it contains its address)
	 */

	i = foo();	/* put the result of `foo' into `i' */

	bar = &foo;	/* put the address of `foo' into a function pointer */

	i = (*bar)();	/* invoke the function whose address is in `bar' */

	bar = foo;	/* ERROR: function assignment */

	i = bar();	/* ERROR: call of non-function */

	foo = printf;	/* ERROR: `foo' is non-modifiable (const) */

A function would be a very special object: you can only take its address or
invoke it; you wouldn't even be allowed to assign it to another variable.
I find the scheme presented above more logical than the `function-to-
function-pointer-conversion' stuff: just compare with `normal' pointers.

BTW, I understand the whole mess pretty well; it's just the `dubious'
behavior that bothers me.
-- 
C, the programming language that's the same |Maarten Litmaath @ VU Amsterdam:
         in all reference frames.           |maart@cs.vu.nl, mcvax!botter!maart