if main should return 0, why there exist EXIT_SUCCESS?
do I have to do this :to make my program portable?Code:#include <stdio.h> #include <stdlib.h> int main (void) { /* blablabla... */ return(EXIT_SUCCESS); }
if main should return 0, why there exist EXIT_SUCCESS?
do I have to do this :to make my program portable?Code:#include <stdio.h> #include <stdlib.h> int main (void) { /* blablabla... */ return(EXIT_SUCCESS); }
Do not stare at my avatar.
main() is not required to return zero. It is allowed to return any int value.
By convention, if main() returns zero or EXIT_SUCCESS (if the values are different) then the program is deemed to have been terminated successfully. So, to indicate success, you are allowed to return 0 or EXIT_SUCCESS. If the macro EXIT_SUCCESS expands to zero then there is no difference between the two options.
My guess is for symmetry with EXIT_FAILURE. I suspect that before C was standardized, 0 was universally recognized as a successful exit (at least as far as C implementations go), but there were different ideas for what non-zero codes meant. Thus EXIT_FAILURE was invented to allow a portable program to signal failure; and since there was an EXIT_FAILURE, why not an EXIT_SUCCESS as well? 0 would still be success, but now you can use a macro if you'd like. Why EXIT_SUCCESS isn't simply defined to be 0 I'm not sure, since 0 is required to mean success as well.if main should return 0, why there exist EXIT_SUCCESS?
Actually... it's done so the program can inform it's host process of errors that occured.
For Example: Batch files (in Windows command shells) can actually use the returned values in conditional branching... IF ERRORLEVEL== and GOTO are commonly used as a means to control the behavior of complex batch processes.
One other reasons is the portability and the code readability. Using macros would ofcourse make much easier in reading code. If for example
Of course you would use the binary there, instead the hex would be used. But you understand the point I’m trying to make.Code:#define SIG_AUTH_REQ 010110 #define SIG_AUTH_RSP 001010 if SIG_RECV == SIG_AUTH_REG calculate AUTH_REP send SIG_AUTH_RSP
ssharish
Life is like riding a bicycle. To keep your balance you must keep moving - Einstein
does EXIT_SUCCESS always expand to 0 on all system/OS ?
Do not stare at my avatar.
The C standard allows EXIT_SUCCESS to expand to a value other than zero. In practice, I've yet to encounter a system where EXIT_SUCCESS does not expand to zero. However, there are quite a few systems I have not worked with.
Same thread from years ago...
exit(-3)
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
You misunderstood.
If you reread my post, you'll see that I'm talking solely about why EXIT_SUCCESS exists when it needn't (since this was the OP's question).
EXIT_FAILURE still exists to allow a portable program to signal failure, as I said. You cannot signal exit failure in a portable manner without using EXIT_FAILURE, but you can signal exit success in a portable manner without using EXIT_SUCCESS.
In practice, the OS does not care what value a user program exits with. The only software which looks at user program exit values is other user programs. It's up to these programs to define what the exit codes mean. EXIT_SUCCESS and EXIT_FAILURE are suggested values to use to indicate success or failure.
The OS doesn't care a whit about whether your program "succeeded" or "failed," it doesn't even define what these codes mean, it just takes the exit code and stores it somewhere so another program can check what value it is.
There's nothing stopping me from writing a program which launches another program, gets its exit code, and treats the value 0 as a failure. It's just not conventional.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
They're the same thing. Most people recognize 0 as being the successful return value. I'm sure return (EXIT_SUCCESS) doesn't return anything different.
Originally Posted by The Jargon File