(* func)(fred, bert)

[Doug Gwyn]

In article <812 at bbm.UUCP> darcy at druid.UUCP (D'Arcy J.M. Cain) writes:
>In article <0175 at sheol.UUCP> throopw at sheol.UUCP (Wayne Throop) writes:
>>> dg at lakart.UUCP (David Goodenough)
>>> void main()
>>It is well worth mentioning (again) that it is NOT a good idea
>>to lie to your compiler in this way.  The main routine of a C
>>program is NOT void.  It returns an int.
>So what?  If you exit your program through some cleanup routine (perhaps
>from a signal trap as well) then returning a value from main is an error
>in the context of your program.  I use the GNU compiler with all the 
>warning levels turned on and declaring main an int would cause a warning
>in just about every program I have written since they don't return a value.
>I don't think it is "lying" to your compiler to do this.  It is simply
>declaring your exact intention of what you plan to do in main.

Wayne's right and you're wrong.  In a hosted environment main() has
several special properties.  One of them is that its type is
int()(int,char**) (in ANSI C, the compiler must also arrange for
int main(void) to work, which may necessitate a special compiler kludge
just for that one case).  In general in C, functions must be defined
with types compatible with their invocations, because details of the
function linkage can (and often do) depend on the specific type.
The start-up module, in environments that use one, is invoking main()
as a function that WILL return an integer value.  If you either
define main() differently or define it properly but fail to arrange
for an integer to be returned, the startup module can get confused
or simply die when the improper return linkage is executed.

What you wish main() would have looked like is irrelevant; you must
match the implementation's expectations or suffer the consequences.
In your particular case, you appear to have an environment where
you can get away with type mismatch.  However, your code is not
portable.