(* func)(fred, bert)

[Dr. T. Andrews]

In article <0200 at sheol.UUCP>, throopw at sheol.UUCP (Wayne Throop) writes:
) can't supply a real world example ... [but have architectures which ]
) would be predisposed to display the flaw, and could very well do so.
Hey, a good conjecture is sufficient for the moment.

) Consider a registerless CISC architecture, ... [return value by
) stashing it in hidden temp on the stack]
) The normal position of this "hidden" actual was argument "0", ...
) bumping all the actuals by 1 stack position.
A compiler writer who wanted to make a more useful compiler would
quite likely discover the "quality of implementation" soon, and
start pushing the temp so that it didn't interfere with the other
arguments (hiding it down at the bottom of the call frame instead
of the top).

It should also be noted that "main()" has been singled out for
special treatment in subroutine linkages, that it might be declared
"main(void)" or "main(argc,argv)".  A sop to the common practice
of declaring it void because it didn't return a value would have
been a good idea.

) Further, consider that exit(2) might well be implemented in such a way
) as to have to attempt to clean up the stack in more detail than is
) common in many UNIX systems.
No problem.  So long as main() didn't return, the linkages are still
intact on the stack.

) But years of established practice, going back into the mists of the
) time before there ever WAS a void type, make "main" an int-returning
) routine.  To declare it otherwise is other than wise.
Not really.  Before there was a "void", people just said "main()",
accepting that the return type would be "int" by default.  Generally
exiting was accomplished by calling exit().  Since it didn't return,
the return type wasn't considered much of a problem.

When "void" came along, so did a proliferation of honest programmers
who declared main to be "void" because it didn't return a value.
-- 
Mulroney: "Cut trains.  Drive in | {bpa,uunet}!cdin-1!cdis-1!tanner
Canada.  We need the acid rain." | {attctc gatech!uflorida}!ki4pv!cdis-1!tanner