bp@swamp.cis.ufl.edu (Brian Pane) (09/17/90)
I've already received one kind e-mail response correcting my earlier
posting on the permissibility of prototyping "int main();," and I hope
people will read this before wasting the bandwith with flames to the
newsgroup.
My point, though perhaps not well stated, was that the declaration
"int main();" would clash with the definition "int main(int argc,
char* argv[]) {} ." Yes, you can get away with "int main(); int main() {},"
with g++ anyway, but the actual parameters corresponding to argc and argv
are still there. (Assuming that that's how your OS works, assuming that
the system even has an OS, etc.)
The only reason you'd want to prototype main() is to call it from
somewhere else; in such a case, it ought to be called with the right
arguments, though a main defined as "int main() { /* ... */ }" wouldn't
attempt to access any arguments anyway, so it wouldn't really matter
that argc and argv were placed on the stack only before the first
invocation of main.
-Brian Paneleo@atcmp.nl (Leo Willems) (09/17/90)
From article <24449@uflorida.cis.ufl.EDU>, by bp@swamp.cis.ufl.edu (Brian Pane): > > I've already received one kind e-mail response correcting my earlier > posting on the permissibility of prototyping "int main();," and I hope > stuff deleted > The only reason you'd want to prototype main() is to call it from > somewhere else; in such a case, it ought to be called with the right stuff deleted You are not allowed to call main from within a program (sec 3.4 E&S). If you want to you you're on your own.... Leo
jimad@microsoft.UUCP (Jim ADCOCK) (09/18/90)
In article <24449@uflorida.cis.ufl.EDU> bp@swamp.cis.ufl.edu (Brian Pane) writes: |My point, though perhaps not well stated, was that the declaration |"int main();" would clash with the definition "int main(int argc, |char* argv[]) {} ." Yes, you can get away with "int main(); int main() {}," |with g++ anyway, but the actual parameters corresponding to argc and argv |are still there. (Assuming that that's how your OS works, assuming that |the system even has an OS, etc.) | |The only reason you'd want to prototype main() is to call it from |somewhere else; in such a case, it ought to be called with the right |arguments, though a main defined as "int main() { /* ... */ }" wouldn't |attempt to access any arguments anyway, so it wouldn't really matter |that argc and argv were placed on the stack only before the first |invocation of main. Hm. Reading E&S 3.4 I get a slightly different impression of the situation of "main" than the other many responders. First, note that while we often call main a "function" -- its actually a special function, and need not obey the same properties as a normal function, nor need a compiler implement it as such. In particular, its not legal to explicitly call main, nor to take its address. [It might not be implemented in a callable manner, and it might not have an address] A compiler should support two or more forms of main: int main() int main(int argc, char* argv[]) int main(int argc, char* argv[], ....????) where ....???? is any implementation required extensions. For example, some operating systems may make additional environmental information available as parameters after argv in the calling list. It seems to me, the above list implies main is implicitly predeclared -- it wouldn't be legal to declare a form of main that a particular compiler was unable to support. Is it legal to declare a main of the form above? [There's no reason to do so, but if one does so, what of it?] Seems like the right answer in any case is not to redeclare main. [You're explicitly not allowed to overload main -- IE you can't add to the list of prototype mains a compiler already supports] One common reason to *attempt* to explicitly call main is to perform C++ startup actions [static inits, etc] from another language, such as C. Such approaches generally require hackery, and are not portable. There is no portable way to perform such start-up actions from other languages, because various C++ compilers can and do differ on how to accomplish them. Perhaps the best strategy is to write all significant code outside of main, and then just use main to call another routine to do all the real work.