> Since I knew the target system is going to be 64bit Linux
Knowing the target system makes a lot of these things quite a bit easier. I had really good luck in college knowing our graphics teacher was using a 286.
As a TA you pretty much can be a hardass or save time for the rest of the semester and just mark 100.
Another early scenario was declaring main() as void in some embedded systems. I guess there was nothing to return to but it was still odd.
N1256 5.1.2.2.3 p1: If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
main() is __cdecl__ or __stdcall__ on the major platforms.
That calling convention on x86 specifies that the return value is red from the EAX register. So, when your main() function exits, the return value is red from EAX, it's that simple.
The compilers may add boilerplate code around the main, in fact main() is rarely the real main() function, but that doesn't change the spec.
The two comments are not incompatible, they are just very different worldviews. One tells you what the standard says (that the termination status is unspecified if main does not return an int), the other tells you what usually happens (you get what happened to be in AX).
And as I've just tested, gcc doesn't return zero termination status if you reach the } at the end of main.
Calling conventions are as much a standard as the C spec.
The main() is called like a regular function, by the system thing that executes programs.
Depending on the compiler and the flags, the main() is not the real entry point of the program. It can add another entry point to do some magic, like setting the return code.
Absolutely not. You can look at a crashing programs and see the return code is a random value. You can also make a program that doesn't return anything and see that it's also a random value, though some compilers on some platforms might initialize that to zero.
MSVC doesn't claim to implement C99, where this rule was added, so it kind of makes sense that it doesn't happen. (generally, if they added C99-stuff then only where it was required for C++)
I love C but this whole thread highlights a lot of the criticism of it. Everyone's right based on some standard or switch, and everyone's wrong for the same reason.
This is not specific to C, but common to all evolving standards. If you want portable code just drive on the middle of the road.
Often this is as easy as coding to an older standard, like C89 with a few selected features from later standards, and adding some compatibility features / problem detection in the build system.
And don't rely on features that are difficult to explain and/or add only questionable value. Just return 0 from main, it's the obvious simple thing to do.
Knowing the target system makes a lot of these things quite a bit easier. I had really good luck in college knowing our graphics teacher was using a 286.
As a TA you pretty much can be a hardass or save time for the rest of the semester and just mark 100.
Another early scenario was declaring main() as void in some embedded systems. I guess there was nothing to return to but it was still odd.