In addition to the other answers: The c++ spec guarantees that all static initialization has happened before main is called.

If code could call main then some static scoped object could call main, in which case a fundamental guarantee is violated.

The spec can’t say “static scoped objects should not call main()” because many objects are not written specifically to be instantiated at static scope always. It also can’t say that constructors should not call main() – because its very difficult to audit and prove that a constructor isn’t calling a method, calling a method, that might sometimes, call main().

I’d imagine this preserves an implementation’s freedom to prefix main with code to construct globals and statics, accept any parameters identifying the environment and command line arguments and map them to the argc/argv/env conventions of C++, construct an appropriate stack and exception framework for the application to execute etc. Consider that not all environments may allow an executable image to have any other symbol designated as initialisation code to be run before main().

Similarly, cleanup code may be appended to main(), along with a call to the OS with some mapping from the 0/non-zero convention of C and C++ to the actual success/failure values used by that specific OS.

Consequently, calling main from elsewhere could attempt a second reinitialisation of the application framework or force an unintended exit to the OS – sounds catastrophic to me.

C++’s main() is a strange little function that has different syntax for exception-handling, doesn’t have to return a value, even though it has to be defined as returning int, etc. I don’t know whether this affects any real implementations, but I would guess that the restriction exists to give compiler writers some latitude in how they implement main().