EXIT_SUCCESS guaranteed to always be zero?

Discussion in 'C Programming' started by Mantorok Redgormor, Nov 25, 2003.

  1. Finally, control is returned to the host environment. If the value of
    status is zero or EXIT_SUCCESS, an implementation-defined form of the
    status successful termination is returned.

    beyond this paragraph from the standard, I can't determine if this
    macro
    will always be zero. It would surely be convenient if it is but it
    never
    states this directly. the "zero or" part, leads me to believe that the
    macro
    can be something other than zero, but I'm not too sure.

    --
    nethlek
     
    Mantorok Redgormor, Nov 25, 2003
    #1
    1. Advertising

  2. Mantorok Redgormor

    Alex Guest

    In comp.lang.c Mantorok Redgormor <> wrote:
    > Finally, control is returned to the host environment. If the value of
    > status is zero or EXIT_SUCCESS, an implementation-defined form of the
    > status successful termination is returned.


    > beyond this paragraph from the standard, I can't determine if this
    > macro
    > will always be zero. It would surely be convenient if it is but it
    > never
    > states this directly. the "zero or" part, leads me to believe that the
    > macro
    > can be something other than zero, but I'm not too sure.


    You are correct. The wording of the standard does not dictate the
    value of EXIT_SUCCESS, nor EXIT_FAILURE.

    All you have to know is that 0 and EXIT_SUCCESS are functional
    synonyms that denote successful program completion. In fact,
    the value returned to the environment does necessarily have
    to correspond to the value returned within the program. It
    just has to indicate that the program completed successfully,
    in an implementation defined manner.

    Alex
     
    Alex, Nov 25, 2003
    #2
    1. Advertising

  3. Mantorok Redgormor

    Ben Pfaff Guest

    (Mantorok Redgormor) writes:

    > beyond this paragraph from the standard, I can't determine if
    > this macro will always be zero. It would surely be convenient
    > if it is but it never states this directly. the "zero or" part,
    > leads me to believe that the macro can be something other than
    > zero, but I'm not too sure.


    The standard doesn't state or imply that EXIT_SUCCESS is always
    0, so you can't portably depend on it.
    --
    "Your correction is 100% correct and 0% helpful. Well done!"
    --Richard Heathfield
     
    Ben Pfaff, Nov 25, 2003
    #3
  4. Alex <> writes:
    > In comp.lang.c Mantorok Redgormor <> wrote:
    > > Finally, control is returned to the host environment. If the value of
    > > status is zero or EXIT_SUCCESS, an implementation-defined form of the
    > > status successful termination is returned.

    >
    > > beyond this paragraph from the standard, I can't determine if this
    > > macro will always be zero. It would surely be convenient if it is but
    > > it never states this directly. the "zero or" part, leads me to believe
    > > that the macro can be something other than zero, but I'm not too sure.

    >
    > You are correct. The wording of the standard does not dictate the
    > value of EXIT_SUCCESS, nor EXIT_FAILURE.
    >
    > All you have to know is that 0 and EXIT_SUCCESS are functional
    > synonyms that denote successful program completion. In fact,
    > the value returned to the environment does necessarily have
    > to correspond to the value returned within the program. It
    > just has to indicate that the program completed successfully,
    > in an implementation defined manner.


    0 and EXIT_SUCCESS aren't necessarily synonymous (though the wording
    in the standard could be read to indicate that they are). They could
    indicate different kinds of success. Of course, a portable program
    can't make use of the distinction, if any.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    (Note new e-mail address)
     
    Keith Thompson, Nov 25, 2003
    #4
  5. Mantorok Redgormor

    nobody Guest

    "Ben Pfaff" <> wrote in message
    news:...
    > (Mantorok Redgormor) writes:
    >
    > > beyond this paragraph from the standard, I can't determine if
    > > this macro will always be zero. It would surely be convenient
    > > if it is but it never states this directly. the "zero or" part,
    > > leads me to believe that the macro can be something other than
    > > zero, but I'm not too sure.

    >
    > The standard doesn't state or imply that EXIT_SUCCESS is always
    > 0, so you can't portably depend on it.


    7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
    -----------------------------------------^^^^^^^^^^^^^^^^^^^^
    an implementation-defined form of the status successful
    termination is returned. ...

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

    If those two together are not "statement", aren't they
    at least implication?

    Related question of my own (I asked about this topic
    some months ago and don't want to seem obtuse - just want
    to understand issues). Standard talks about returning to
    the host environment. Only way I know of to (portably?)
    execute another (C) program from C program is system()
    call. However, 7.20.4.5p3 states (about system()) "If the
    argument is not a null pointer, and the system function
    does return, it returns an implementation-defined value."
    Doesn't it all together imply that success/failure of
    a C program can be portably "returned", but not "retrieved"
    (in a portable manner)? If yes, then *portable* "return to
    host environment" doesn't make much sense, does it? (I'm
    not interested in portable return to e.g. Java program).
    (If no,) I will really appreciate clarification (as
    always, even if I don't state so).
    Thanks. (It's not sig, I'm not impersonating Tom:)
     
    nobody, Nov 25, 2003
    #5
  6. Mantorok Redgormor

    Ben Pfaff Guest

    "nobody" <> writes:

    > "Ben Pfaff" <> wrote in message
    > news:...
    > > (Mantorok Redgormor) writes:
    > >
    > > > beyond this paragraph from the standard, I can't determine if
    > > > this macro will always be zero. It would surely be convenient
    > > > if it is but it never states this directly. the "zero or" part,
    > > > leads me to believe that the macro can be something other than
    > > > zero, but I'm not too sure.

    > >
    > > The standard doesn't state or imply that EXIT_SUCCESS is always
    > > 0, so you can't portably depend on it.

    >
    > 7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
    > -----------------------------------------^^^^^^^^^^^^^^^^^^^^
    > an implementation-defined form of the status successful
    > termination is returned. ...


    If EXIT_SUCCESS is always zero, then why the "or"?

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


    Nothing to do with the former statement.

    > If those two together are not "statement", aren't they
    > at least implication?


    No.
    --
    "I hope, some day, to learn to read.
    It seems to be even harder than writing."
    --Richard Heathfield
     
    Ben Pfaff, Nov 25, 2003
    #6
  7. On Tue, 24 Nov 2003, Ben Pfaff wrote:
    >
    > "nobody" <> writes:
    > > "Ben Pfaff" <> wrote...
    > > >
    > > > The standard doesn't state or imply that EXIT_SUCCESS is always
    > > > 0, so you can't portably depend on it.

    > >
    > > 7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
    > > -----------------------------------------^^^^^^^^^^^^^^^^^^^^
    > > an implementation-defined form of the status successful
    > > termination is returned. ... ^^^

    >
    > If EXIT_SUCCESS is always zero, then why the "or"?


    [Because it is possible that (EXIT_SUCCESS != 0).]

    > > If those two together are not "statement", aren't they
    > > at least implication?

    >
    > No.


    I see the problem here. IMHO, EXIT_SUCCESS and zero *are*
    synonymous *in the context of a call to exit()*. Note that
    I've added a line under the word "the" in 7.20.4.3p5, which
    to me indicates that there is only one possible status
    "successful termination" in C, and it's triggered by both
    0 and EXIT_SUCCESS, equivalently.
    However, 0 and EXIT_SUCCESS are obviously *not* equivalent
    in all contexts. To take the canonical extreme example,

    void *p = 0;
    void *q = EXIT_SUCCESS;

    are certainly not equivalent! But I do believe the Standard
    guarantees that

    exit(0);
    exit(EXIT_SUCCESS);

    are exactly equivalent under all implementations, no matter
    the actual integer value of EXIT_SUCCESS.

    -Arthur
     
    Arthur J. O'Dwyer, Nov 25, 2003
    #7
  8. nobody wrote:
    > 5.1.2.2.3p1 ... reaching the } that terminates the main
    > function returns a value of 0. ...


    which is one form of returning a successful termination
    status to the invoking environment. EXIT_STATUS could
    have a value different from 0, and in fact it did on
    VAX/VMS at one point in time (the system convention was
    that even-values status returns indicated failure and
    odd-values ones success, but since there was no failure
    code 0 the C run-time system was able to convert any 0
    return into an odd value before handing it back to the
    environment).

    > Doesn't it all together imply that success/failure of
    > a C program can be portably "returned", but not "retrieved"
    > (in a portable manner)? If yes, then *portable* "return to
    > host environment" doesn't make much sense, does it? (I'm
    > not interested in portable return to e.g. Java program).


    It makes plenty of sense, for example to use programs
    properly in Unix shell scripts they must correctly
    indicate whethr they succeeded or failed. Similarly
    for other host command environments. There is more to
    computing than just C.
     
    Douglas A. Gwyn, Nov 25, 2003
    #8
  9. Mantorok Redgormor

    Mike Wahler Guest

    "Arthur J. O'Dwyer" <> wrote in message
    news:p...
    >
    > On Tue, 24 Nov 2003, Ben Pfaff wrote:
    > >
    > > "nobody" <> writes:
    > > > "Ben Pfaff" <> wrote...
    > > > >
    > > > > The standard doesn't state or imply that EXIT_SUCCESS is always
    > > > > 0, so you can't portably depend on it.
    > > >
    > > > 7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
    > > > -----------------------------------------^^^^^^^^^^^^^^^^^^^^
    > > > an implementation-defined form of the status successful
    > > > termination is returned. ... ^^^

    > >
    > > If EXIT_SUCCESS is always zero, then why the "or"?

    >
    > [Because it is possible that (EXIT_SUCCESS != 0).]
    >
    > > > If those two together are not "statement", aren't they
    > > > at least implication?

    > >
    > > No.

    >
    > I see the problem here. IMHO, EXIT_SUCCESS and zero *are*
    > synonymous *in the context of a call to exit()*. Note that
    > I've added a line under the word "the" in 7.20.4.3p5, which
    > to me indicates that there is only one possible status
    > "successful termination" in C, and it's triggered by both
    > 0 and EXIT_SUCCESS, equivalently.
    > However, 0 and EXIT_SUCCESS are obviously *not* equivalent
    > in all contexts. To take the canonical extreme example,
    >
    > void *p = 0;


    Here, the 0 does not signify an integral zero, but a null pointer.

    > void *q = EXIT_SUCCESS;


    The behavior of this is implementation defined.

    >
    > are certainly not equivalent! But I do believe the Standard
    > guarantees that
    >
    > exit(0);
    > exit(EXIT_SUCCESS);
    >
    > are exactly equivalent under all implementations, no matter
    > the actual integer value of EXIT_SUCCESS.


    Right, because in both these cases the argument is an integer
    value, with the pointer examples above, it is not.

    -Mike
     
    Mike Wahler, Nov 25, 2003
    #9
  10. Mantorok Redgormor

    Dan Pop Guest

    In <> (Mantorok Redgormor) writes:

    >Finally, control is returned to the host environment. If the value of
    >status is zero or EXIT_SUCCESS, an implementation-defined form of the
    >status successful termination is returned.
    >
    >beyond this paragraph from the standard, I can't determine if this
    >macro
    >will always be zero. It would surely be convenient if it is but it
    >never
    >states this directly. the "zero or" part, leads me to believe that the
    >macro
    >can be something other than zero, but I'm not too sure.


    Please explain why do you think it matters whether EXIT_SUCCESS can be
    something else than zero or not. Are you planning to use EXIT_SUCCESS
    instead of zero in other contexts than exit() calls?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 25, 2003
    #10
  11. Mantorok Redgormor

    Dan Pop Guest

    In <> Keith Thompson <> writes:

    >Alex <> writes:
    >> In comp.lang.c Mantorok Redgormor <> wrote:
    >> > Finally, control is returned to the host environment. If the value of
    >> > status is zero or EXIT_SUCCESS, an implementation-defined form of the
    >> > status successful termination is returned.

    >>
    >> > beyond this paragraph from the standard, I can't determine if this
    >> > macro will always be zero. It would surely be convenient if it is but
    >> > it never states this directly. the "zero or" part, leads me to believe
    >> > that the macro can be something other than zero, but I'm not too sure.

    >>
    >> You are correct. The wording of the standard does not dictate the
    >> value of EXIT_SUCCESS, nor EXIT_FAILURE.
    >>
    >> All you have to know is that 0 and EXIT_SUCCESS are functional
    >> synonyms that denote successful program completion. In fact,
    >> the value returned to the environment does necessarily have
    >> to correspond to the value returned within the program. It
    >> just has to indicate that the program completed successfully,
    >> in an implementation defined manner.

    >
    >0 and EXIT_SUCCESS aren't necessarily synonymous (though the wording
    >in the standard could be read to indicate that they are).


    Then, how do you know they aren't? The most natural interpretation of
    the text is that they have the *same* effect.

    >They could indicate different kinds of success.


    This is far from obvious from the standard.

    >Of course, a portable program
    >can't make use of the distinction, if any.


    Especially since the distinction (if any) happens *after* the program
    termination ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 25, 2003
    #11
  12. Mantorok Redgormor

    Wojtek Lerch Guest

    "Mike Wahler" <> wrote in message
    news:L9Ewb.14238$...
    > "Arthur J. O'Dwyer" <> wrote in message
    > news:p...
    > > However, 0 and EXIT_SUCCESS are obviously *not* equivalent
    > > in all contexts. To take the canonical extreme example,
    > >
    > > void *p = 0;

    >
    > Here, the 0 does not signify an integral zero, but a null pointer.
    >
    > > void *q = EXIT_SUCCESS;

    >
    > The behavior of this is implementation defined.


    If the value is nonzero, this is a constraint violation.

    And I don't think the value of EXIT_SUCCESS is implementation-defined. At
    least as far as I can tell, the standard never says that it is. Doesn't
    that make it unspecified?

    > > exit(0);
    > > exit(EXIT_SUCCESS);
    > >
    > > are exactly equivalent under all implementations, no matter
    > > the actual integer value of EXIT_SUCCESS.

    >
    > Right, because in both these cases the argument is an integer
    > value, with the pointer examples above, it is not.


    But where does the standard say it's *exactly* equivalent? If an
    implementation detects the difference and displays slightly different
    messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
    termination (EXIT_SUCCESS)"), how does that make it non-conforming?
     
    Wojtek Lerch, Nov 25, 2003
    #12
  13. Mantorok Redgormor

    James Kuyper Guest

    nobody wrote:
    >
    > "Ben Pfaff" <> wrote in message
    > news:...

    ....
    > > The standard doesn't state or imply that EXIT_SUCCESS is always
    > > 0, so you can't portably depend on it.

    >
    > 7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
    > -----------------------------------------^^^^^^^^^^^^^^^^^^^^
    > an implementation-defined form of the status successful
    > termination is returned. ...
    >
    > 5.1.2.2.3p1 ... reaching the } that terminates the main
    > function returns a value of 0. ...
    >
    > If those two together are not "statement", aren't they
    > at least implication?


    They are statements, but they don't imply that EXIT_SUCCESS is always
    zero. In fact, the "or" strongly implies that EXIT_SUCCESS doesn't have
    to be the same as zero.

    > Related question of my own (I asked about this topic
    > some months ago and don't want to seem obtuse - just want
    > to understand issues). Standard talks about returning to
    > the host environment. Only way I know of to (portably?)
    > execute another (C) program from C program is system()
    > call. However, 7.20.4.5p3 states (about system()) "If the
    > argument is not a null pointer, and the system function
    > does return, it returns an implementation-defined value."
    >
    > Doesn't it all together imply that success/failure of
    > a C program can be portably "returned", but not "retrieved"
    > (in a portable manner)? If yes, then *portable* "return to
    > host environment" doesn't make much sense, does it? (I'm
    > not interested in portable return to e.g. Java program).


    Correct. Code of that kind cannot be written to be portable across all
    environments where the C standard is the only one you can rely on.
    However, if you restrict yourself to a narrower range of environments,
    where stronger guarantees by other standards (such as POSIX) apply, then
    it can be portable.
     
    James Kuyper, Nov 25, 2003
    #13
  14. On Tue, 25 Nov 2003, Wojtek Lerch wrote:
    >
    > "Mike Wahler" <> wrote...
    > > "Arthur J. O'Dwyer" <> wrote...
    > > >
    > > > However, 0 and EXIT_SUCCESS are obviously *not* equivalent
    > > > in all contexts. To take the canonical extreme example,
    > > >
    > > > void *p = 0;

    > >
    > > Here, the 0 does not signify an integral zero, but a null pointer.


    Yes, it was a poor example. A better example would have been

    if (EXIT_SUCCESS != 0)
    puts("Hello");

    ....but that's kind of boring, isn't it? :)


    > > > void *q = EXIT_SUCCESS;

    > >
    > > The behavior of this is implementation defined.

    >
    > If the value is nonzero, this is a constraint violation.


    Right.

    > And I don't think the value of EXIT_SUCCESS is implementation-defined. At
    > least as far as I can tell, the standard never says that it is. Doesn't
    > that make it unspecified?


    Nope. "Unspecified," in a C context, means that there are only a few
    well-specified alternatives, and that the implementation must pick
    one of them. "Implementation-defined" means that the implementation
    has free range to define EXIT_SUCCESS however it likes, within certain
    parameters. As I read the Standard, the value of EXIT_SUCCESS is
    implementation-defined.


    > > > exit(0);
    > > > exit(EXIT_SUCCESS);
    > > >
    > > > are exactly equivalent under all implementations, no matter
    > > > the actual integer value of EXIT_SUCCESS.

    > >
    > > Right, because in both these cases the argument is an integer
    > > value, with the pointer examples above, it is not.

    >
    > But where does the standard say it's *exactly* equivalent? If an
    > implementation detects the difference and displays slightly different
    > messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
    > termination (EXIT_SUCCESS)"), how does that make it non-conforming?


    IMO, that would violate the sentence whose operative word I
    specifically underlined in the original quote:

    [#5] Finally, control is returned to the host environment.
    If the value of status is zero or EXIT_SUCCESS, an
    implementation-defined form of the status successful
    termination is returned. ^^^

    If the platform has more than one traditional form of the "status
    successful" termination, it must *pick one* to be *the* status
    successful termination for its C implementation. You can't have
    two different "*the* status successful terminations"!

    -Arthur
     
    Arthur J. O'Dwyer, Nov 25, 2003
    #14
  15. "Arthur J. O'Dwyer" <> writes:
    > On Tue, 25 Nov 2003, Wojtek Lerch wrote:

    [...]
    > > And I don't think the value of EXIT_SUCCESS is implementation-defined. At
    > > least as far as I can tell, the standard never says that it is. Doesn't
    > > that make it unspecified?

    >
    > Nope. "Unspecified," in a C context, means that there are only a few
    > well-specified alternatives, and that the implementation must pick
    > one of them. "Implementation-defined" means that the implementation
    > has free range to define EXIT_SUCCESS however it likes, within certain
    > parameters. As I read the Standard, the value of EXIT_SUCCESS is
    > implementation-defined.


    "Implementation-defined" also means that the implementation has to
    document the choice it makes. There's no requirement to document the
    value of EXIT_SUCCESS.

    [...]
    > > But where does the standard say it's *exactly* equivalent? If an
    > > implementation detects the difference and displays slightly different
    > > messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
    > > termination (EXIT_SUCCESS)"), how does that make it non-conforming?

    >
    > IMO, that would violate the sentence whose operative word I
    > specifically underlined in the original quote:
    >
    > [#5] Finally, control is returned to the host environment.
    > If the value of status is zero or EXIT_SUCCESS, an
    > implementation-defined form of the status successful
    > termination is returned. ^^^
    >
    > If the platform has more than one traditional form of the "status
    > successful" termination, it must *pick one* to be *the* status
    > successful termination for its C implementation. You can't have
    > two different "*the* status successful terminations"!


    It's clear that EXIT_SUCCESS can have a value other than 0. It's not
    entirely clear, at least to me, that exit(0) and exit(EXIT_SUCCESS)
    are entirely equilvalent. The standard refers to "*the* status
    successful termination", but also refers to "*an*
    implementation-defined form" of that status. In my opinion, the
    quoted paragraph can be interpreted to allow 0 and EXIT_SUCCESS to
    indicate two different forms of "the status successful termination".
    In other words:

    If the value of status is zero, an implementation-defined form of
    the status successful termination is returned. If the value of
    status is EXIT_SUCCESS, an implementation-defined form of the
    status successful termination is returned.

    I agree that it could also be read to require both to return the same
    form of the status successful termination, but I think my
    interpretation makes more sense, especially in environment (like VMS)
    with multiple ways to indicate success. (On the other hand, there's
    no portable way to take advantage of any difference between exit(0)
    and exit(EXIT_SUCCESS). If the authors of the standard had wanted to
    guarantee that exit(0) and exit(EXIT_SUCCESS) are exactly equivalent,
    they could have required that EXIT_SUCCESS == 0.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    (Note new e-mail address)
     
    Keith Thompson, Nov 25, 2003
    #15
  16. Mantorok Redgormor

    Mike Wahler Guest

    "Keith Thompson" <> wrote in message
    news:...
    > In other words:
    >
    > If the value of status is zero, an implementation-defined form of
    > the status successful termination is returned. If the value of
    > status is EXIT_SUCCESS, an implementation-defined form of the
    > status successful termination is returned.
    >
    > I agree that it could also be read to require both to return the same
    > form of the status successful termination, but I think my
    > interpretation makes more sense, especially in environment (like VMS)
    > with multiple ways to indicate success. (On the other hand, there's
    > no portable way to take advantage of any difference between exit(0)
    > and exit(EXIT_SUCCESS). If the authors of the standard had wanted to
    > guarantee that exit(0) and exit(EXIT_SUCCESS) are exactly equivalent,
    > they could have required that EXIT_SUCCESS == 0.


    In which case there would have been no need to define
    the 'EXIT_SUCCESS' macro at all. :)

    -Mike
     
    Mike Wahler, Nov 25, 2003
    #16
  17. Mantorok Redgormor

    James Kuyper Guest

    "Arthur J. O'Dwyer" wrote:
    >
    > On Tue, 25 Nov 2003, Wojtek Lerch wrote:
    > >
    > > "Mike Wahler" <> wrote...
    > > > "Arthur J. O'Dwyer" <> wrote...


    > > And I don't think the value of EXIT_SUCCESS is implementation-defined. At
    > > least as far as I can tell, the standard never says that it is. Doesn't
    > > that make it unspecified?

    >
    > Nope. "Unspecified," in a C context, means that there are only a few
    > well-specified alternatives, and that the implementation must pick
    > one of them. "Implementation-defined" means that the implementation
    > has free range to define EXIT_SUCCESS however it likes, within certain
    > parameters. As I read the Standard, the value of EXIT_SUCCESS is
    > implementation-defined.


    Implementation-defined is a subset of "unspecified". The alternatives
    for "unspecified" are not required to be "few", the only requirement is
    that there be at least two of them. In this case, EXIT_SUCCESS can be
    defined as expanding into any string of characters that constitutes an
    integer constant expression that can be safely converted to an int; the
    expression's value need not itself be within the valid range of an int.
    There is a discrete infinity of such expressions, which becomes finite,
    but still huge, if you put an upper limit on the length of that
    character string.
     
    James Kuyper, Nov 25, 2003
    #17
  18. (Dan Pop) wrote in message news:<bpvm56$9pc$>...
    > In <> (Mantorok Redgormor) writes:
    >
    > >Finally, control is returned to the host environment. If the value of
    > >status is zero or EXIT_SUCCESS, an implementation-defined form of the
    > >status successful termination is returned.
    > >
    > >beyond this paragraph from the standard, I can't determine if this
    > >macro
    > >will always be zero. It would surely be convenient if it is but it
    > >never
    > >states this directly. the "zero or" part, leads me to believe that the
    > >macro
    > >can be something other than zero, but I'm not too sure.

    >
    > Please explain why do you think it matters whether EXIT_SUCCESS can be
    > something else than zero or not. Are you planning to use EXIT_SUCCESS
    > instead of zero in other contexts than exit() calls?
    >
    > Dan


    well I was using EXIT_FAILURE in a few functions to serve as a
    failure returned. which is why I was ensuring if EXIT_SUCCESS
    is guaranteed to be zero, which it isn't. So that route is messy.

    I guess I could instead use

    #define FAILURE 1
    #define SUCCESS 0


    --
    nethlek
     
    Mantorok Redgormor, Nov 25, 2003
    #18
  19. Mantorok Redgormor

    Eric Sosman Guest

    Mantorok Redgormor wrote:
    >
    > (Dan Pop) wrote:
    > >
    > > Please explain why do you think it matters whether EXIT_SUCCESS can be
    > > something else than zero or not. Are you planning to use EXIT_SUCCESS
    > > instead of zero in other contexts than exit() calls?
    > >
    > > Dan

    >
    > well I was using EXIT_FAILURE in a few functions to serve as a
    > failure returned. which is why I was ensuring if EXIT_SUCCESS
    > is guaranteed to be zero, which it isn't. So that route is messy.


    Also dangerous, at least in theory. As far as I can
    tell, the Standard permits EXIT_FAILURE == EXIT_SUCCESS
    on an implementation where programs don't have a termination
    status at all and the "implementation-defined form" thereof
    is vacuous.

    > I guess I could instead use
    >
    > #define FAILURE 1
    > #define SUCCESS 0


    Or something like that. It's a little counter-intuitive
    that `if (FAILURE)' tests out as true, so it's probably best
    to form the habit of writing `if (func() == SUCCESS)' instead.

    --
     
    Eric Sosman, Nov 25, 2003
    #19
  20. Mantorok Redgormor

    Tim Woodall Guest

    On Tue, 25 Nov 2003 14:30:38 GMT,
    Wojtek Lerch <> wrote:
    > "Mike Wahler" <> wrote in message
    > news:L9Ewb.14238$...
    >> "Arthur J. O'Dwyer" <> wrote in message
    >> news:p...
    >>
    >> > void *q = EXIT_SUCCESS;

    >>
    >> The behavior of this is implementation defined.

    >
    > If the value is nonzero, this is a constraint violation.
    >

    Why? It must be an integer (or convert to an integer) in order for
    it to be a valid return from main. And integers can be converted
    to pointers in an implementation defined way.

    Tim.

    --
    God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
    and there was light.

    http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
     
    Tim Woodall, Nov 25, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Zhiqiang Ye
    Replies:
    53
    Views:
    10,288
    Dan Pop
    Jun 28, 2004
  2. Gerard Flanagan
    Replies:
    3
    Views:
    452
    Terry Hancock
    Nov 19, 2005
  3. Christopher Benson-Manica

    Doubles and zero/negative zero

    Christopher Benson-Manica, Jun 30, 2004, in forum: C Programming
    Replies:
    4
    Views:
    684
    Walter
    Jul 1, 2004
  4. William Payne
    Replies:
    13
    Views:
    860
    Dave Thompson
    Sep 8, 2004
  5. joes
    Replies:
    2
    Views:
    1,022
    Daniel Pitts
    May 25, 2007
Loading...

Share This Page