🚀 go-pugleaf

In article <6165@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>A recent posting of the Boyer-Moore string search algorithm, written in C,
>contained several assignment statements in which a pointer to a function
>was assigned depending on circumstances.  The designated function was then
>called to do its thing.  The definition and call looked like this:
>
>   int (*action)();
>        .
>        .
>        .
>    if(action(arg1, arg2))
>        etc;
>
>and the pcc under 4.3bsd compiled everything without comment.  The C compiler
>written by Microsoft (v 3.0) was unhappy with the function call, however,
>insisting "action : not a function."

The Microsoft C compiler is of course correct.  'Action' is a pointer to
a function, and proper use would be to dereference the pointer as shown
immediately below.  It is regrettable that PCC (and hence PCC-based compilers)
allow this sloppy construct without at least issuing a warning.

>A quick look in K&R failed to reveal a call of the above format, but they
>suggested one which looks like this:
>
>   if((*action)(arg1, arg2))
>        etc;
>
>When I substituted the above form for the original, Microsoft C compiled the
>program without complaint and the code executed correctly; the pcc apparently
>will accept either format.
>
>Is the original format documented anywhere?  Is it "standard" C or not?

It most certainly is *not* standard, and I would dare say it is sloppy form.

---
Kenneth R. Ballou		...!ucbvax!cartan!brahms!ballou
Dept. of Mathematics
University of California
Berkeley, California  94720
Newsgroups: net.lang.c
Subject: Re: Calling functions via pointers
Summary: 
Expires: 
References: <6165@ut-sally.UUCP>
Sender: 
Reply-To: ballou@brahms (Kenneth R. Ballou)
Followup-To: 
Distribution: 
Organization: Math Dept. UC Berkeley
Keywords: 

> >Is the original format documented anywhere?  Is it "standard" C or not?
> 
> It most certainly is *not* standard, and I would dare say it is sloppy form.

I don't like it either, but it *is* in the current ANSI C draft.  (Then
again, I don't like C's "array expression converts to pointer expression"
rules either.)  See section 3.3.2.2; it says "The expression that denotes
the function shall have type 'pointer to function'.", with a footnote
pointing out that "Most often, this is the result of converting an
identifier that is a function designator."  Thus, in the statement

	foo(x);

where "foo" was earlier declared as a function (or where it is implicitly
declared as a function by reference, but only Don't Be(e)s do this), the
name "foo" immediately gets converted to type "pointer to function", that
"pointer" gets "dereferenced" and the resulting function is called.  In the
example being complained about, in the statement

	if (action(arg1, arg2))
		etc;

the pointer "action" is dereferenced and the function is called.  If you say

	if ((*action)(arg1, arg2))
		etc;

"action" is dereferenced; this yields an object of type "function", but they
can't appear in expressions so it immediately gets converted back to type
"pointer to function"; that pointer value (identical to the value of
"action") is then dereferenced and the function is called.

It does make a perverse kind of sense, I suppose, if you think about it,
just as the similar handling of array types and array-valued expressions
does.  (If anyone wants to object that "C doesn't have array-valued
expressions", I refer them to section 3.2.2.1 in the latest ANSI C draft,
where they speak of "expressions that ha(ve) type 'array of <type>'.")

If you want the rationale for why this was done, check the Rationale
document that came with the latest ANSI C draft.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)

It's a common "corruption" of C, based on the question:
"Shucks, it's a pointer to a function; what the heck else are ya gonna
 do with the dang thing except dereference it, i.e. call what it points to?"

Technically, the explicit dereference is required, i.e. ((*action)())
Pcc-based implementation imply the dereference as necessary. I don't even know
if 4.[23] lint would complain about this one.
--
This is not an official statement of Hewlett-Packard Corp., and does not 
necessarily reflect the views of HP. It is provided completely without warranty
of any kind. Lawyers take 3d10 damage and roll a saving throw vs. ego attack.

Jason Zions				Hewlett-Packard
Colorado Networks Division		3404 E. Harmony Road
Mail Stop 102				Ft. Collins, CO  80525
	{ihnp4,seismo,hplabs,gatech}!hpfcdc!hpcnoe!jason