Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!hao!oddjob!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.lang.c
Subject: Re: Another portable code question
Message-ID: <7048@mimsy.UUCP>
Date: Mon, 15-Jun-87 00:07:49 EDT
Article-I.D.: mimsy.7048
Posted: Mon Jun 15 00:07:49 1987
Date-Received: Tue, 16-Jun-87 01:47:52 EDT
References: <16673@cca.CCA.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 46

In article <16673@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes:
>int (*command)();
>....
>(*command)(args);

vs

>"(command)(args)"

>One vendor's compiler ... gives a compilation warning for (*command)().
>... The PRIMOS C compiler rejects (command)(args) and insists
>upon (*command)(args).

The PRIMOS C compiler is within its rights; K&R have said to use
the first form.  The dpANS recommends the second form.  When the
draft standard is adopted, and assuming that its recommendation
still stands, the PRIMOS compiler will have to be changed.  The
compiler that gives a warning for (*command)(args) is making useless
noise.

Incidentally, PCC accepts all sorts of strange things:

	x()
	{
		int (*f)(), g();

		f = g;
		(*f)(1);
		f(1);
		(***f)(1);
		g(1);
		(*g)(1);
		(**g)(1);
	}

If you look at it properly, this is not so strange after all:
Values of type `function' are changed to values of type `pointer
to function' in most contexts.  Why not change them thus even in
function call contexts, and then allow

	pointer-to-function '(' argument-list ')' ';'

and accept either form?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris