Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!oliveb!sun!guy
From: guy@sun.UUCP
Newsgroups: comp.lang.c
Subject: Re: Another portable code question
Message-ID: <21067@sun.uucp>
Date: Sun, 14-Jun-87 17:13:07 EDT
Article-I.D.: sun.21067
Posted: Sun Jun 14 17:13:07 1987
Date-Received: Tue, 16-Jun-87 00:42:49 EDT
References: <16673@cca.CCA.COM> <1122@copper.TEK.COM>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 80

> > (b)	One vendor's compiler gives a compilation warning for (*command)().
> > 
> > (c)	The PRIMOS C compiler rejects (command)(args) and insists
> > upon (*command)(args)
>
> I believe that the compiler mentioned on observation (b) is
> incorrect.

The compiler mentioned on observation (b) is incorrect.  According to
K&R:

	7.1 Primary expressions

	...

	   A function call is a primary expression followed by
	parentheses containing a possibly empty, comma-separated list
	of expressions which constitute the actual arguments to the
	function.  The primary expression must be of type "function
	returning..." ...

And, if "command" is of type "pointer to function returning...",
"*command" is clearly of type "function returning.

ANSI C is a bit different:

	3.3.2.2 Function calls

	Constraints

	   The expression that denotes the function called shall have
	type ``pointer to function''.

Since an expression of type "function" gets converted to an
expression of type "pointer to function" that points to that
function, in most cases - see

	3.3.0.1 Lvalues and function designators

	...

	   A "function designator" is an expression that has function
	type.  If a function designator appears in a context where
	such an operand is not permitted, it is converted to a
	pointer as described in \(sc 3.2.2.1.  The result is not a
	function designator

and

	3.2.2.1 Arrays, functions, and pointers

	...

	   Except when used as an operand where a function designator
	is permitted, an identifier declared as ``function returning
	"type"'' is converted to an expression that has type
	``pointer to function returning "type".''

- either (*command)(args) or command(args) is permitted by ANSI C.

So it seems that K&R permits (b) but not (c), while ANSI C permits
both of them.  I'm not sure I like this either, but that's life.

> This may be a perpetuation of the (possibly
> misguided) trend of issuing warnings for &array.

Actually, ANSI C changes the *meaning* of "&array", so that it is an
expression of type "pointer to array" rather than an expression of
type "pointer to what the array is made out of".  As such, this trend
will come to an end once the ANSI C standard leaves draft status.
(Fortunately, this is one of the easiest pieces of ANSI C to
implement in PCC - all you have to do is delete some code, namely the
code in "mip/cgram.y" that tests whether the "&" operator is being
applied to something of type "array" or "function", issues a warning,
and eliminates the "&" operator.  It's always nice to improve
something without having to add code....)
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)