return from main

[junky_fellow]

Guys,

Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

thanks for any help...

[Richard Heathfield]

ju**********@yahoo.co.in said:

Guys,

Can I return 0, from main() ?

Yes.

Is this equivalent to exit(EXIT_SUCCESS) ?

Yes in practice. In theory, EXIT_SUCCESS and 0 both represent successful
termination but the Standard doesn't forbid them from having different
values and representing different kinds of success! (I don't know of any
implementations that distinguish between them in this way, and it is
likely that there are no such implementations.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

<http://c-faq.com/>, question 11.16, or read any decent C reference.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

ju**********@yahoo.co.in said:

>>
Can I return 0, from main() ?

Yes.

>Is this equivalent to exit(EXIT_SUCCESS) ?

Yes in practice. In theory, EXIT_SUCCESS and 0 both represent successful
termination but the Standard doesn't forbid them from having different
values and representing different kinds of success! (I don't know of any
implementations that distinguish between them in this way, and it is
likely that there are no such implementations.)

Obscure exceptions: recursive calls to main() and atexit()-registered
functions that refer to local variables declared in main().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

ju**********@yahoo.co.in wrote:

Guys,

Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

thanks for any help...

According to Google Groups, you (or someone using your
alias) have been participating in comp.lang.c since February
of 2004. Since you are still asking basic, first-ten-days
questions after more than four and a half years, I suspect
your abilities lie elsewhere than in computer programming
and I urge you to seek a different sphere of activity.

Or just to stop trolling.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[junky_fellow]

On Nov 12, 6:30 pm, Eric Sosman <[e-mail]:

[e-mail] wrote:

Guys,

Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

thanks for any help...

According to Google Groups, you (or someone using your
alias) have been participating in comp.lang.c since February
of 2004. Since you are still asking basic, first-ten-days
questions after more than four and a half years, I suspect
your abilities lie elsewhere than in computer programming
and I urge you to seek a different sphere of activity.

Or just to stop trolling.

First of all, Sorry, for asking the similar and such basic questions
again and again.

The reason why I asked this question is because I was not able to
undertand the following lines (mentioned in n1124.pdf at page 13.

"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;10) 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."

The wordings are really confusing. Whenever, I read these lines, I
endup in one or other kind of confusion.
Still, the meaning is unclear to me.

[Mark Bluemel]

ju**********@yahoo.co.in wrote:

The reason why I asked this question is because I was not able to
undertand the following lines (mentioned in n1124.pdf at page 13.

If I reformat and comment, does it help?

"If the return type of the main function is a type compatible with
int,

i.e. if your code starts with int main(<something>)
(and it must in a hosted environment, as I understand it)

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;

i.e. return(x) in main is equivalent to exit(x)
(in the initial call - recursive calls are, naturally, different)

reaching the } that terminates the main function returns
a value of 0.

i.e. dropping off the bottom of main() is equivalent to exit(0)

If the return type is not compatible with int, the
termination status returned to the host environment is unspecified."

That should be clear.

(I do wonder whether you should really be spending much time on
reading the standard - a good reference text may be much more useful
to you.)

[Richard Heathfield]

Keith Willis said:

On Tue, 13 Nov 2007 08:49:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>
1) always define main as either:

(a) int main(void)

or:

(b) int main(int argc, char **argv)

Shudder! I am well aware that C != C++, but if one inadvertantly uses
form (a) in "that other froup down the hall", they all start foaming
at the mouth, so because I have to use both languages these days, I
have made something of a point never to use that form :-)

I always use int main(void) for no-args programs, even in C++. Watching C++
programmers foaming at the mouth is good for the soul.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Philip Potter]

Keith Willis wrote:

On Tue, 13 Nov 2007 08:49:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>1) always define main as either:

(a) int main(void)

or:

(b) int main(int argc, char **argv)

Shudder! I am well aware that C != C++, but if one inadvertantly uses
form (a) in "that other froup down the hall", they all start foaming
at the mouth, so because I have to use both languages these days, I
have made something of a point never to use that form :-)

For code which will be compiled as either C or C++ (including many
headers), it is far more desirable to use f(void); because in C++
f(void) is identical semantically to f(), but in C f() has a different
meaning to f(void) and f() will supress a lot of useful compiler warnings.

If you're only writing C++, do what you like. If you're writing which
will be compiled as C, then always use C prototypes.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Spiros Bousbouras]

On Nov 13, 8:38 am, "[e-mail]"
<[e-mail]:

First of all, Sorry, for asking the similar and such basic questions
again and again.

The reason why I asked this question is because I was not able to
undertand the following lines (mentioned in n1124.pdf at page 13.

"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;10) 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."

The wordings are really confusing. Whenever, I read these lines, I
endup in one or other kind of confusion.
Still, the meaning is unclear to me.

The return type of main() is implementation defined. So it
says that if in the implementation you're working with main()
has a return type which is compatible with int then reaching
the end of main() returns the value 0. What "compatible type"
means is defined elsewhere in the standard. On the other hand
if the return type of main() is not compatible with int then
in the absence of an explicit return followed by an expression,
the value returned to the environment is unspecified. The meaning
of "unspecified" is also defined in the standard.

[Mark Bluemel]

ju**********@yahoo.co.in wrote:

The reason why I had a trouble understanding the lines is due to the
fact that, I was interpreting these lines as follows:

".. 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."

I was interpreting the above as a single line.

http://en.wikipedia.org/wiki/Semicolon

Perhaps, if they would have used "Reaching" instead of "reaching",

And replaced the semicolon with a period (full stop)

it would have been easier for the readers to undertsnat it as follows:

Expecting others to impoverish their writing simply due to ignorance of
punctuation seems a little unfair...

[Note - "ignorance" here is used in a purely descriptive sense. I tend
to favour ignorance over stupidity, as ignorance is curable]

[James Kuyper]

ju**********@yahoo.co.in wrote:
....

The reason why I asked this question is because I was not able to
undertand the following lines (mentioned in n1124.pdf at page 13.

"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;

In other words, your program's true start point isn't really main(). The
start-up code performs whatever processing is needed prior to calling
main(), such as setting up the argv array. Then it acts as if it were
compiled from C code that contains either the line

exit(main());

or

exit(main(argc, argv));

or whatever other interfaces to main that it supports.

If you think about it this way, I hope that it's obvious why 'return x;'
is equivalent to 'exit(x);' only in the initial call to main(), and not
in any recursive calls. However, recursive calls to main() are such a
bizarre thing to do that you ordinarily wouldn't have any reason to use
them, particular if you want to compile the same code in C++, where they
are not allowed.

[Charlie Gordon]

"James Kuyper" <ja*********@verizon.neta écrit dans le message de news:
nHg_i.6165$763.178@trnddc07...

ju**********@yahoo.co.in wrote:
...

>The reason why I asked this question is because I was not able to
undertand the following lines (mentioned in n1124.pdf at page 13.

"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;

In other words, your program's true start point isn't really main(). The
start-up code performs whatever processing is needed prior to calling
main(), such as setting up the argv array. Then it acts as if it were
compiled from C code that contains either the line

exit(main());

or

exit(main(argc, argv));

or whatever other interfaces to main that it supports.

If you think about it this way, I hope that it's obvious why 'return x;'
is equivalent to 'exit(x);'

There is a subtle difference: calling exit() from main invokes the functions
registered with atexit with main's local variables still valid. Returning
from main will invoke exit with the return value, but main's local variables
will have been destroyed and any function registered with atexit referencing
them invokes undefined behaviour, that applies to the argc argv arguments
and potentially also to the strings pointed to by the argv array.

--
Chqrlie.

[jameskuyper]

Charlie Gordon wrote:

"James Kuyper" <ja*********@verizon.neta écrit dans le message de news:

....

In other words, your program's true start point isn't really main(). The
start-up code performs whatever processing is needed prior to calling
main(), such as setting up the argv array. Then it acts as if it were
compiled from C code that contains either the line

exit(main());

or

exit(main(argc, argv));

or whatever other interfaces to main that it supports.

If you think about it this way, I hope that it's obvious why 'return x;'
is equivalent to 'exit(x);'

I should have said "roughly equivalent". I was aware of the exception
you describe:

There is a subtle difference: calling exit() from main invokes the functions
registered with atexit with main's local variables still valid. Returning
from main will invoke exit with the return value, but main's local variables
will have been destroyed and any function registered with atexit referencing
them invokes undefined behaviour, that applies to the argc argv arguments
and potentially also to the strings pointed to by the argv array.

In practice, I doubt that this case comes up very often. I didn't want
to complicate my response further by mentioning that exception.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Wed, 14 Nov 2007 11:22:15 +0000, Spiros Bousbouras wrote:

On Nov 13, 6:53 pm, Keith Thompson <[e-mail]:

>Spiros Bousbouras <[e-mail]:

The return type of main() is implementation defined.

Saying that the return type of main() is implementation defined may be
a little bit misleading. All hosted implementations must support a
return type of int.

We must be reading the beginning of 5.1.2.2.1 differently.

I don't believe you are. Let's say a silly implementation supports
char main(int argc, wchar_t *argv[])
as an extension. It doesn't have to also allow
int main(int argc, wchar_t *argv[])
but since it still must support
int main(int argc, char *argv[])
it does have to support a return type of int. This is consistent with
both your message and Keith's, unless I am the one misreading here.

[Peter Nilsson]

Keith Willis <[e-mail]:

I abandoned the use of void as an argument type
meaning ''no arguments'' after Dennis Ritchie and
Doug McIlroy strongly condemned it as ''an abomination.''
Instead, I adopted the obvious notation for taking no
arguments, an empty pair of parentheses.
For example:
int f (void ); // error: abomination
int g (); // g takes no argument

Does anyone know where they condemnded it ?

Since posting the link to Stroustrup's PDF, I've been
looking for the source of the original comments by
Ritchie and McIlroy, but no luck.

Chances are it was a corridor discussion.

--
Peter

[Barry Schwarz]

On Tue, 13 Nov 2007 12:15:24 +0000, Mark Bluemel
<ma**********@pobox.comwrote:

>ju**********@yahoo.co.in wrote:

>The reason why I had a trouble understanding the lines is due to the
fact that, I was interpreting these lines as follows:

".. 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."

I was interpreting the above as a single line.

http://en.wikipedia.org/wiki/Semicolon

Perhaps, if they would have used "Reaching" instead of "reaching",

And replaced the semicolon with a period (full stop)

it would have been easier for the readers to undertsnat it as follows:

Expecting others to impoverish their writing simply due to ignorance of
punctuation seems a little unfair...

[Note - "ignorance" here is used in a purely descriptive sense. I tend
to favour ignorance over stupidity, as ignorance is curable]

Considering that it is supposed to be an international standard, it
wouldn't hurt for the writers to consider their readers for whom
English is not the native language. However, since it was written by
committee, clarity was probably not a primary consideration.

In any case, the sentence expresses two completely unrelated, actually
mutually exclusive, concepts. It would hardly impoverish the writing
if they gave each concept its own sentence.
Remove del for email

[Keith Thompson]

Spiros Bousbouras wrote:
[...]

How does it follow from the part of the standard that I quoted
that it has to support the two standard forms ? It seems to me
that as long as it satisfies the indented part below the or
meaning the part reading "or in some other implementation-defined
manner" then it can ignore the part above the or. If one of the
two clauses of an or is satisfied then that's good enough , isn't
it ? Although reading the 2nd paragraph of 5.1.2.2.1 perhaps
the intention was that it must always satisfy the part above the
or. If that was the intention then it's not at all clearly phrased.

5.1.2.2.1 specifies requirements for a program, not for an implementation. Note
paragraph 1: "It shall be defined ...". The implementation doesn't define main;
the program does. The implementation's job is to accept any program that meets
the requirements.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Peter Nilsson]

Keith Thompson <[e-mail]:

Richard Heathfield <[e-mail]:

[e-mail] said:

Can I return 0, from main() ?

Yes.

Is this equivalent to exit(EXIT_SUCCESS) ?

Yes in practice. In theory, EXIT_SUCCESS and 0 both
represent successful termination but the Standard
doesn't forbid them from having different values and
representing different kinds of success! (I don't
know of any implementations that distinguish between
them in this way, and it is likely that there are no
such implementations.)

Perhaps none now, but in the past it was certainly a
possibility on some of the VAX systems.

Obscure exceptions: recursive calls to main() and
atexit()-registered functions that refer to local
variables declared in main().

Perhaps more critical to that scenario is that
EXIT_FAILURE need not have a non-zero value or be
different to EXIT_SUCCESS.

--
Peter

[Keith Thompson]

Peter Nilsson wrote:

Keith Thompson <[e-mail]:

>Richard Heathfield <[e-mail]:

>>[e-mail] said:
Can I return 0, from main() ?
Yes.

Is this equivalent to exit(EXIT_SUCCESS) ?
Yes in practice. In theory, EXIT_SUCCESS and 0 both
represent successful termination but the Standard
doesn't forbid them from having different values and
representing different kinds of success! (I don't
know of any implementations that distinguish between
them in this way, and it is likely that there are no
such implementations.)

Perhaps none now, but in the past it was certainly a
possibility on some of the VAX systems.

Under VMS (which isn't quite dead, and runs on both VAX and Alpha
hardware, and possibly others), the OS convention is that returning an
even number from a program indicates success, and returning an odd
number indicates failure. This obviously conflicts with the convention
of using exit(0) to indicate success. However, the C runtime works
around this by translating "exit(0)" or "return 0" so that it returns
the value 1 (indicating success) to the environment. It *doesn't* do a
similar translation for "exit(1)".

As I recall (from using VMS about 10 years ago), EXIT_SUCCESS is defined
as 0, and EXIT_FAILURE is defined as some non-zero even number (perhaps
2). So exit(0) and exit(EXIT_SUCCESS) are exactly equivalent, even
under VMS.

This may have been different in the distant past.

>Obscure exceptions: recursive calls to main() and
atexit()-registered functions that refer to local
variables declared in main().

Perhaps more critical to that scenario is that
EXIT_FAILURE need not have a non-zero value or be
different to EXIT_SUCCESS.

True, but if the OS provides a way for a program to indicate success or
failure, it will almost certainly define EXIT_FAILURE as a non-zero
value different from the value of EXIT_SUCCESS. If the OS has no such
mechanism, then the C implementation might as well define both
EXIT_SUCCESS and EXIT_FAILURE as 0 -- but I don't know of any such systems.

Given that both exit(0) and exit(EXIT_SUCCESS) must indicate success (if
that's possible), I can't think of any reason for EXIT_SUCCESS to have a
value other than 0.

In my opinion, requiring exit(0) (or return 0) to denote success was an
over-specification. Traditionally, in Unix, exit(0) indicates success,
and exit(1) indicates a non-specific failure. The C standard broke the
latter, but not the former.

I suppose the rationale was that if there were no guarantees about
exit(0), then any program that wants to terminate normally must have a
"#include <stdlib.h>" so it can use EXIT_SUCCESS.

If C89 hadn't required 0 to denote success, then C99's rule about
falling off the end of main would actually have made sense; it could
have said that reaching the closing "}" is equivalent to returning
EXIT_SUCCESS. But that's not what happened.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Pfaff]

Keith Thompson <ks***@mib.orgwrites:

Under VMS (which isn't quite dead, and runs on both VAX and Alpha
hardware, and possibly others), the OS convention is that returning an
even number from a program indicates success, and returning an odd
number indicates failure. This obviously conflicts with the
convention of using exit(0) to indicate success.

0 is an even number.
--
Ben Pfaff
http://benpfaff.org

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.eduwrites:

Keith Thompson <ks***@mib.orgwrites:

>Under VMS (which isn't quite dead, and runs on both VAX and Alpha
hardware, and possibly others), the OS convention is that returning an
even number from a program indicates success, and returning an odd
number indicates failure. This obviously conflicts with the
convention of using exit(0) to indicate success.

0 is an even number.

D'oh!

What I *meant* to say is that returning an even number indicates
failure, and returning an odd number indicates success.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ben Pfaff wrote:

Keith Thompson <ks***@mib.orgwrites:

>Under VMS (which isn't quite dead, and runs on both VAX and Alpha
hardware, and possibly others), the OS convention is that returning an
even number from a program indicates success, and returning an odd
number indicates failure. This obviously conflicts with the
convention of using exit(0) to indicate success.

0 is an even number.

D'oh!

What I *meant* to say is that returning an even number indicates
failure, and returning an odd number indicates success.

(Sorry if you see this twice; I initially posted through rr.com, which
is under a UDP.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
fh**********@aioe.org...

Ben Pfaff wrote:

>Keith Thompson <ks***@mib.orgwrites:

>>Under VMS (which isn't quite dead, and runs on both VAX and Alpha
hardware, and possibly others), the OS convention is that returning an
even number from a program indicates success, and returning an odd
number indicates failure. This obviously conflicts with the
convention of using exit(0) to indicate success.

0 is an even number.

D'oh!

What I *meant* to say is that returning an even number indicates
failure, and returning an odd number indicates success.

(Sorry if you see this twice; I initially posted through rr.com, which is
under a UDP.)

I saw it only once ;-)
What is a UDP ?

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

What is a UDP ?

In this context, it stands for "Usenet Death Penalty". It's a sort of mass
plonk, inflicted by news server administrators on an errant peer who is
failing to discipline abusive users.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Spiros Bousbouras]

On Nov 15, 9:03 pm, Keith Thompson <[e-mail]:

Spiros Bousbouras wrote:

[...]

How does it follow from the part of the standard that I quoted
that it has to support the two standard forms ? It seems to me
that as long as it satisfies the indented part below the or
meaning the part reading "or in some other implementation-defined
manner" then it can ignore the part above the or. If one of the
two clauses of an or is satisfied then that's good enough , isn't
it ? Although reading the 2nd paragraph of 5.1.2.2.1 perhaps
the intention was that it must always satisfy the part above the
or. If that was the intention then it's not at all clearly phrased.

5.1.2.2.1 specifies requirements for a program, not for an implementation. Note
paragraph 1: "It shall be defined ...". The implementation doesn't define main;
the program does. The implementation's job is to accept any program that meets
the requirements.

Ok , I see it now.

[CBFalconer]

"ju**********@yahoo.co.in" wrote:

>
Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

Yes.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Mon, 12 Nov 2007 18:33:41 -0500, CBFalconer wrote:

"ju**********@yahoo.co.in" wrote:

>>
Can I return 0, from main() ? Is this equivalent to
exit(EXIT_SUCCESS) ?

Yes.

No, for multiple reasons, as has been explained in this thread already.