Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!tektronix!teklds!copper!stevesu
From: stevesu@copper.UUCP
Newsgroups: comp.lang.c
Subject: Re: Another portable code question
Message-ID: <1122@copper.TEK.COM>
Date: Sat, 13-Jun-87 17:29:52 EDT
Article-I.D.: copper.1122
Posted: Sat Jun 13 17:29:52 1987
Date-Received: Sun, 14-Jun-87 18:37:10 EDT
References: <16673@cca.CCA.COM>
Organization: Tektronix Inc., Beaverton, Or.
Lines: 40
Summary: (*funcptr)() is correct

In article <16673@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes:
> ...on a wide variety of UNIX systems the line "(*command)(args);"
> may be written as "(command)(args)".  We have observed:
> 
> (a)	On most UNIX machines (VAX BSD and Sun in particular) either
> form is acceptable and will compile and execute correctly.
> 
> (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.  This may be a perpetuation of the (possibly
misguided) trend of issuing warnings for &array.

I have always thought about it this way:  if "command" is a
pointer to a function, then I have to slap a "*" in front of it
before I have a real function that I can stick an argument list
on and call.

Many compilers seem to make the "*" optional, reasoning that
the only possible use for a function pointer, especially in
a function call context, is to indirect on it and call it.
I wish they wouldn't, since this only leads to confusion and
misunderstanding, as you've discovered.  (Throwing well-defined
rules out the window and applying weird heuristics in an attempt
to do what the programmer meant and not what he said violates
what I feel to be one of the fundamental tenets of the Unix
philosophy.  One of the reasons that programming on VMS is such a
screaming nightmare is that there are very few hard-and-fast
rules you can apply in attempting to predict the system's
behavior, since so many undocumented special cases have been
inserted so as to "do the right thing.")

So, to answer your question, (*command)(args) is correct and
should be maximally (but, sadly, not universally) portable.

                                           Steve Summit
                                           stevesu@copper.tek.com