Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Calling functions via pointers

14 views
Skip to first unread message

Ed Nather

unread,
Oct 30, 1986, 1:40:11 PM10/30/86
to
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."

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?

--
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nat...@astro.AS.UTEXAS.EDU

Kenneth R. Ballou

unread,
Oct 30, 1986, 10:32:49 PM10/30/86
to
In article <61...@ut-sally.UUCP> nat...@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: <61...@ut-sally.UUCP>
Sender:
Reply-To: ballou@brahms (Kenneth R. Ballou)
Followup-To:
Distribution:
Organization: Math Dept. UC Berkeley
Keywords:

Henry Spencer

unread,
Oct 31, 1986, 5:45:48 PM10/31/86
to
> ... '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.

It is doubly unfortunate that X3J11 has legitimized it, last I looked.
Boo, hiss. I can sympathize with the arguments that (a) there is no other
conceivable meaning, so it doesn't hurt anything, and (b) it reduces
code breakage, but I still don't like it.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry

Guy Harris

unread,
Oct 31, 1986, 6:11:47 PM10/31/86
to
> >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
g...@sun.com (or g...@sun.arpa)

Jason Zions

unread,
Nov 2, 1986, 5:00:18 PM11/2/86
to
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

0 new messages