prototype my function, please

[D'Arcy J.M. Cain]

In article <0705 at sheol.UUCP> throopw at sheol.UUCP (Wayne Throop) writes:
>> I get the bad feeling that I am going to get flamed for this...
>No, but my reply may revive a long-forgotten flame-war...
>
Yes but what else is Usenet for? :-)

> [..]
>However, nobody seems to have noticed the other type gaffe, namely
>
>> void main(){...}
>
>The function named "main" in C environments is not how, and has never been,
>of type (void ()).  At the very least, it should be declared as returning
>an (int), and best of all is to declare it completely, with argc and argv and
>the whole nine yards.
>
>Remember: there is a contract with that fragment of your C environment
>that invokes the main routine (often called "crt0" for reasons unknown to me)
>which says that the routine will return an integer value.  It is unwise
>to lie to the compiler in this way.
But if you always use exit() to end your program, isn't it sort of lying
to tell C that you will return an int?  As I recall that previous "flame
war" The problem with declaring main to return void was that the function
startup sequence might be different for different or no returns.  I can't
recall if anyone actually came up with an ANSI C compiler that had this
property but I am sure it is rare at best.  I think that if any compiler
acts this way it should handle the special case of main somehow.  At the
very least it should internally prototype main.  The best way of handling
it would be to use whatever the programmer declares to check return types
but to set the function call as if it had been declared properly.

So can anyone summarize the ANSI compilers (or K&R1 compilers for that
matter) for which decalaring main to return void causes a problem?

-- 
D'Arcy J.M. Cain (darcy at druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
(416) 281-6094                     |