M
Mark McIntyre
Sure. Whats your point?
The rtl is quite entitled to convert 0 and EXIT_SUCCESS into whatever
it actually likes, but it needn't.
Mark McIntyre
Sure. Whats your point?
The rtl is quite entitled to convert 0 and EXIT_SUCCESS into whatever
it actually likes, but it needn't.
Mark McIntyre
E
Eric Sosman
Jordan Abel wrote On 03/28/06 14:26,:
A programmer familiar with VMS is as familiar with
the notion of different kinds of success as others are
with different kinds of failure. Such notions arise in
everyday life, too: Did your favorite college basketball
time "win" its tournament game, or did it "win in a walk"
or "win in triple overtime?" Yes, all the variations can
be expressed as "win" (VMS condition codes encode a similar
simplification in the low-order bit), but the fact that
the sportscasters communicate the distinction suggests
that someone's believed to be interested in it.
An old joke that needs to be read aloud with a Beebish
intonation: "And now for the results of today's football
matches. Arsenal one, Birmingham lost, ..."
A programmer familiar with VMS is as familiar with
the notion of different kinds of success as others are
with different kinds of failure. Such notions arise in
everyday life, too: Did your favorite college basketball
time "win" its tournament game, or did it "win in a walk"
or "win in triple overtime?" Yes, all the variations can
be expressed as "win" (VMS condition codes encode a similar
simplification in the low-order bit), but the fact that
the sportscasters communicate the distinction suggests
that someone's believed to be interested in it.
An old joke that needs to be read aloud with a Beebish
intonation: "And now for the results of today's football
matches. Arsenal one, Birmingham lost, ..."
J
Jordan Abel
And they'll probably want to use their implementation-defined specific
exit codes instead of picking between 0 and EXIT_SUCCESS. There's no
reason for 0 not to be a synonym for EXIT_SUCCESS, since they're both
equally generic "win"s.
K
Keith Thompson
Mark McIntyre said:
The point, I think, is that "because the OS expects it" is not a
reason to have a value other than 0 for EXIT_SUCCESS. Since 0 is
required to indicate success, defining EXIT_SUCCESS as 0 works just
fine. As far as I know, all implementations define EXIT_SUCCESS as
0 -- even VMS.
If the standard had required EXIT_SUCCESS to be defined as 0, it would
have made no real difference.
It's true that an implementation *may* define EXIT_SUCCESS as
something other than 0, but there's really no reason to do so.
C
CBFalconer
Eric said:
Not so, especially in the embedded world. There none of the
standard library may be used, and the only really interesting
header is stddef.h.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
B
Ben Bacarisse
I am neither Eric nor Keith but I can't resist a thread where there is
some merit in having bean around for a while. I first wrote "hello
world\n" (and I think it was indeed that) in 1978/9. I got the job in '78
but I did not get to use the cool CS types PDP 11 right away so I am not
sure exactly. It was just *before* they got all excited about the Unix
release whose C compiler had long ints and allowed structure assignments
(and function return values).
I played a bit and then got back to the serious stuff with FORTRAN on and
IBM 360 and B (yes B!) on a Honeywell something-or-other.
E
Eric Sosman
CBFalconer wrote On 03/28/06 16:22,:
I should, perhaps, have written "almost every
hosted program." Only "perhaps," though, because the
context you snipped was about using <stdlib.h> to get
the definitions of EXIT_SUCCESS and EXIT_FAILURE.
I'm given to understand that these macros are rather
sparsely used in freestanding code ...
I should, perhaps, have written "almost every
hosted program." Only "perhaps," though, because the
context you snipped was about using <stdlib.h> to get
the definitions of EXIT_SUCCESS and EXIT_FAILURE.
I'm given to understand that these macros are rather
sparsely used in freestanding code ...
K
Keith Thompson
Eric Sosman said:
It would have been reasonable to define EXIT_SUCCESS and EXIT_FAILURE
in all the same headers that currently defined NULL (which is perhaps
the most widely used name from the stnadard headers).
(Context: This is assuming a model in which EXIT_SUCCESS and
EXIT_FAILURE are the only portable values to pass to exit() or to
return from main(), and exit(0), like exit(1) is non-portable. This
would have been cleaner than the model that was adopted, in which
EXIT_SUCCESS and 0 both denote success, but not necessarily in the
same way.)
R
Richard Bos
Jordan Abel said:
Because on OSes where the difference can be significant, it is nice to
be able to return both "program terminated successfully by default" and
"program terminated successfully by explicit decision of the
programmer"?
Richard
M
Mark McIntyre
Sure. On the other hand, there's no reason for EXIT_SUCCESS to be
defined as zero either, since it isn't obligated to be zero.
Mark McIntyre
K
Keith Thompson
Mark McIntyre said:
Sure there is.
Defining EXIT_SUCCESS as something other than 0 means that,
potentially, a program using exit(0) could behave differently than a
program using exit(EXIT_SUCCESS). From a programmer's point of view,
the choice of which one to use normally is (and should be) completely
arbitrary.
If an implementation wants to define multiple successful status codes,
it can define its own; distinguishing between EXIT_SUCCESS and 0 is
just obfuscation.
M
Mark McIntyre
*shrug*. Oh, no he isn't, oh yes he is. Look out behind you.
No. According to the ISO Standard, they /must/ both mean "successful
termination status".
PMF but from the point of view of a C programme, you're talking
bollocks. A C programme knows nothing and cares nothing for what the
OS does after termination. It returns zero or EXIT_SUCCESS, both
indicate it succeeded, if the OS chooses to intrepret 0 and 34567 as
both meaning "successful termination", then fine. Why does the
programmer care?
Mark McIntyre
J
Jordan Abel
But they can mean DIFFERENT successful termination statuses.
J
Jordan Abel
And which one do you suppose would "0" map to, and which EXIT_SUCCESS?
Given that an explicit decision of the programmer is equally likely to
be either, it might make more sense for exit() to do bizarre
platform-specific stuff to figure out where it was called from.
M
Mark McIntyre
So? The standard doesn't care what happens once the OS gets the
message.
Mark McIntyre
K
Keith Thompson
[...]Mark McIntyre said:
But possibly different forms of successful termination status.
C99 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.
The wording is ambiguous. It could mean either:
Zero causes an implementation-defined form of successful
termination.
EXIT_SUCCESS causes an implementation-defined form of successful
termination.
(They needn't be the same form, as long as they both indicate
success.)
or:
Zero or EXIT_SUCCESS causes *the same* implementation-defined form
of successful termination.
I think the first interpretation is more reasonable (YMMV). Under
that interpretation, exit(0) and exit(EXIT_SUCCESS) could behave
differently, by causing two different forms of a successful
termination status to be returned to the host environment.
I'm arguing that an implementation is allowed to make exit(0) and
exit(EXIT_SUCCESS) behave differently (though the difference can't be
detected by the program), not that there's any point in doing so.
K
Keith Thompson
Mark McIntyre said:
All I meant when I said they could "behave differently" is that they
could return different statuses to the environment. Obviously the
program itself can't tell the difference (but another program,
invoking our program via system(), could).
M
Mark McIntyre
Then I think we're agreeing violently with each other...
Mark McIntyre
D
Dave Vandervies
Eric Sosman said:
Butbutbut... Language X *does* "Rulez", and Language Y *does* suck.
It's just that what languages Language X and Language Y are depends on
the task at hand.
F'rexample:
Task: Processing text
Language X: sh+awk+sed, Perl
Language Y: Fortran
Task: Producing write-only code
Language X: APL, Perl
Language Y: COBOL
Task: Making peoples' brains explode
Language X: Forth, Lisp
Language Y: Pascal
ObTopic:
Task: Interfacing with OS (or other) API libraries
Task: Writing code that will compile and run anywhere you can imagine
and a few places you can't
Language X: C
Task: Quickly building a simple GUI program
Task: Teaching good programming habits directly[1]
Language Y: C
dave
[1] Note that C can be pretty good for "Shoot yourself in the foot enough
times in enough different ways and you'll learn how to avoid doing
it", which is sometimes a useful complement to teaching directly.
--
Dave Vandervies (e-mail address removed)
You need to go outside more often.
--Prabhakar Ragde and Doug Payne in uw.general
R
Richard Bos
Jordan Abel said:
0 the unspecific one, and EXIT_SUCCESS the specific.
Possibly; but the other way 'round, EXIT_SUCCESS is more likely to be an
explicit decision than 0. One sees return 0; in lots of sample and
teaching code. EXIT_SUCCESS is rarer.
Richard