I've noticed that programs I compile using gcc don't return a 0 on success. Using g++ they do. I'm curious if this is the expected result or if this is a bug/undocumented feature. I tried on gcc 2.95 and 3.2.

Are these programs you wrote yourself? Or programs written by other people? There is no errno definition as far as I know for a success exit so most people just use 0 but I suppose you could use whatever you want, though it wouldn't make sense to use something defined by the errno.h file for your architecture.

What do you mean by, ``don't return a 0 on success''? Are you referring to the shell not showing a return value when queried or have you disassembled the program?

I'm not using a 'return 0' statement as the last line in my source. I'm checking the return code with echo $?. The default behavior for most processes is 0 for success and I was wondering why g++ uses this behavior but gcc doesn't.

Well it is your responsibility to set the return value. If you encounter an error you return something corresponding to your error, and if you don't you return 0. The compiler isn't just going to guess if your application preformed as you wanted it to. If you have no return statement in your main function then you should be getting a warning when you compile with the -Wall option.

stdlib.h defines 0 as EXIT_SUCCESS

Is that a difference between C and C++ or a difference between gcc and g++? g++ gives no warning and if the program successfully executes it always returns 0 even though I have no return statement.

Well, lets put it this way, if your function is of type int and you don't explicitly return an int then you are not programming the function correctly, regardless of the language. It might work, but it is bad form.

When I compile both of these test programs,

C_EXAMPLE.C
CPP_EXAMPLE.CPP
compiled with:

gcc c_example.c -o c_example -Wall
g++ cpp_example.cpp -o cpp_example -Wall

and then I test them, like this:

it seems both gave 0 as their return value. Were you doing this...

Just so you know, the fact that C program returning 0 is probably dumb luck. C doesn't init anything to a value so you can't expect that to happen.

Yeah, it seems that GCC (well, at least 3.3.1 on IA32) seems to always chuck a `mov $0x0,%eax' into the prologue of the main function. However, 2.95.3 does not, and assume many other version may not - also, other compilers probably will not.

This is what I get with gcc 2.95 and 3.2:

gcc -g -Wall c_exm.c -o c_exm
c_exm.c: In function `main':
c_exm.c:4: warning: control reaches end of non-void function

Using 3.2, I get 0 return codes on both, but adding even 1 statement to the c program gives me a different return code.

Well, why dont you compile your program like this:

gcc -g -S -Wall c_exm.c -o c_exm

and check out the machine code. The reason you get a different return code
by "adding even 1 statement" is that each and every line of C code uses the
machine registers, and it is their contents that determine the return value at the
end of the main procedure.

Ok... apparently I haven't been clear....

You MUST have a return statement in a function that is declared anything other then void in order for any competent programmer to consider the function correctly coded. I don't care if you are using C or C++, I don't care what the warning message is. If you are declaring functions with return values and not returning a value your implementation of that function is poor, and incorrect.

WRONG:
int main{}
{
}

RIGHT:
int main{}
{
return 0;
}

It is perfectly reasonable to place a "return EXIT_SUCCESS;" or "return 0;" as the last line in your function. It is also perfectly reasonable to define a list of error codes if different behaviors occur and return those values. It is NOT reasonable to have no return statement and expect the compiler to clean up your badly written code and make it perform in a consistent manner.