Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site bbncca.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!bbncca!keesan From: keesan@bbncca.ARPA (Morris Keesan) Newsgroups: net.lang.c Subject: Re: Function pointer syntax peculiarity Message-ID: <1178@bbncca.ARPA> Date: Thu, 29-Nov-84 11:35:59 EST Article-I.D.: bbncca.1178 Posted: Thu Nov 29 11:35:59 1984 Date-Received: Fri, 30-Nov-84 06:52:49 EST References: <396@ucsfcgl.UUCP> Organization: Bolt, Beranek and Newman, Cambridge, Ma. Lines: 51 ------------------------------ >From: arnold@ucsfcgl.UUCP (Ken Arnold%CGL) >Looking at the code for qsort(), I came across the following >peculiarity in the syntax and semantics of function pointers. It seems >that "(*cfunc)()" and "cfunc()" are both equivalent uses of a pointer >to a function "cfunc". > >which seems to work. I have tested the code on our 4.2bsd C compiler >(a version of PCC) and both usages generate the same code, and neither >gives a warning message. > >I'm curious what other people think about this. The current situation >in which BOTH syntax 1 and 2 are allowed concurrently is certainly >confusing and nonsensical. I would tend to support a change to syntax >2, with syntax 1 usage generating a warning, as the "=+" operators have >done. > >It is possible this has been dealt with in the proposed C standard, >which I have yet to see more than a summary of. If it is, what is the >solution? The V7 qsort() uses its function pointer correctly, i.e. (*qscmp)(args), where qscmp is declared as pointer to function. The V7 C compiler (cc) does NOT allow the elided form [ qscmp(args) ], and produces the error message "Call of non-function". This is correct behavior according to the C Reference Manual -- Section 7.1, fourth paragraph of page 186 of K&R: "A function call is a primary expression followed by parentheses containing . . . the actual arguments . . . The primary expression must be of type 'function returning ...' . . ." The ability to use functions and function pointers interchangeably looks like it's probably a Berkloid modification. It makes a certain amount of sense. Section 14.2 of the Manual (p. 209, K&R) says, "If the name of a function appears in an expression not in the function-name position of a call, a pointer to the function is generated," and the exhibited behavior in 4.2 is simply a generalization of this to treat the function name as a pointer in all cases, and allow function calls to look the same with or without pointers. However, it is in violation of the language as defined by Kernighan and Ritchie, and this is supported by the behavior of the V7 "cc", which was written by Dennis Ritchie. The October 17, 1984 Draft of the ANSI standard explicitly allows (Section 4.1.2) a function call to have either a function or pointer to function preceding the parentheses. This seems like a reasonable way to remain compatible with the behavior of most or all existing compilers. I would object to removing the original form for calls of function pointers (i.e. with the *), or even giving warnings, as this would break all of the old programs which did it "right", for no good reason (the =+,etc. operators were removed because of ambiguities). -- Morris M. Keesan {decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan keesan @ BBN-UNIX.ARPA