Thread: Newbie question

Originally Posted by matsp

This will do the same thing as the call to main with a void return type - the return value is completely undefined (and thus will contain "any garbage").

Sure, forcing the compiler to call a function that returns void as if it returns an int involves undefined behaviour. In some such circumstances, the code will fail to compile, but (for those who enjoy playing in the realm of undefined behaviour) it is possible to force the issue by use of some casting

Originally Posted by matsp

Of course, in C++ this won't even work, since the name mangling says that int foo(int) is a different function than void foo(int).

I suppose that's one way of looking at it. It is more normally stated as "C++ does not support overloaded functions that differ only in return type". Name mangling doesn't really have anything to do with it, except in code samples like yours where one source file declares the function returns int and another source file does not have a matching declaration, but provides a different definition - in such cases, in practice, the problem becomes evident when linking (the linker will normally complain about undefined symbols or something similar). If, within some translation unit, the compiler (whether C or C++) sees both a declaration and a definition that are different it will complain about a mismatch; that has nothing to do with name mangling.

Originally Posted by matsp

But I beleive that even in a C++ compiler, "main" is implicitly made

Code:

extern "C" int main(/*whatever */);

. So the return type is still not involved in the name of the function.

The C++ standard requires no such thing: the linkage of main() is implementation defined.

Strictly speaking, a C++ compiler is not even required to implement main() as a function.

Originally Posted by matsp

Of course, there are further complications: The call to main may be different for a void main than it is for a int main in some architectures [e.g. one where the return value from a function is passed on the stack], and this could potentially cause problems in those architectures. Just like EBCDIC, I have not experienced an architectuer yet that has this behaviour, but it's entirely concievable to have such an architecture.

These are only complications for the compiler writer who chooses to support non-standard forms of main(). Such concerns would normally not be visible to the programmer (aka user of the compiler) unless said programmer writes code exhibiting undefined behaviour or uses tools (debuggers, etc) that allow visibility of machine-specific implementation details.