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
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:
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
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)
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