nather@ut-sally.UUCP (Ed Nather) (10/30/86)
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 nather@astro.AS.UTEXAS.EDU
ballou@brahms (Kenneth R. Ballou) (10/31/86)
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:
henry@utzoo.UUCP (Henry Spencer) (11/01/86)
> ... '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@sun.uucp (Guy Harris) (11/01/86)
> >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)
jason@hpcnoe.UUCP (Jason Zions) (11/03/86)
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