Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > exit()

Reply
Thread Tools

exit()

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-16-2013
On Fri, 2013-02-15, Alain Ketterlin wrote:
> Keith Thompson <(E-Mail Removed)> writes:

....
>> Some specific commands define meanings for exit statuses other than 0 or
>> 1. For example, the grep command exits with a status of 0 on success, 1
>> on failure, and 2 on error. The curl command defines 88 different error
>> codes, but that's an extreme case.


IME grep is an extreme case too. The vast majority of Unix tools
return 0 for success, and 1 for errors.

> It seems obvious to me that BartC needs something like that.


Why is that obvious? He didn't say anything about his actual problem,
and again: designs which rely on many different exit codes are rare.

Perhaps his needs are best served by printing something to stdout and
returning 0/1.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      02-16-2013


"Jorgen Grahn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> On Fri, 2013-02-15, Alain Ketterlin wrote:


> IME grep is an extreme case too. The vast majority of Unix tools
> return 0 for success, and 1 for errors.
>
>> It seems obvious to me that BartC needs something like that.

>
> Why is that obvious? He didn't say anything about his actual problem,
> and again: designs which rely on many different exit codes are rare.
>
> Perhaps his needs are best served by printing something to stdout and
> returning 0/1.


Sometimes I need to return two values (usually 1 for success, 0 for failure;
the opposite of above); sometimes three or four (an exit code from an editor
for example that may contain a request to compile the result). A range of
0..255, or even a limited subset, would be more than adequate. And better
than having to communicate via files, although this is what I have to do
with programs such as gcc for example, to figure out if something compiled
without errors.

(And on Windows there is a special function to pick up this exit code. While
a system() function exists (and is considerably simpler to use), it's return
value seems unrelated to the exit code of any program it attempts to run.)

--
Bartc

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-16-2013
"BartC" <(E-Mail Removed)> writes:
> "Jorgen Grahn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed). ..
>> On Fri, 2013-02-15, Alain Ketterlin wrote:

>
>> IME grep is an extreme case too. The vast majority of Unix tools
>> return 0 for success, and 1 for errors.
>>
>>> It seems obvious to me that BartC needs something like that.

>>
>> Why is that obvious? He didn't say anything about his actual problem,
>> and again: designs which rely on many different exit codes are rare.
>>
>> Perhaps his needs are best served by printing something to stdout and
>> returning 0/1.

>
> Sometimes I need to return two values (usually 1 for success, 0 for failure;
> the opposite of above); sometimes three or four (an exit code from an editor
> for example that may contain a request to compile the result). A range of
> 0..255, or even a limited subset, would be more than adequate. And better
> than having to communicate via files, although this is what I have to do
> with programs such as gcc for example, to figure out if something compiled
> without errors.


If you need two return values denoting success and failure, you should
use 0 and EXIT_FAILURE, respectively, or EXIT_SUCCESS and EXIT_FAILURE.
If you use `exit(0)` for failure and `exit(1)` for success, your program
won't interoperate with other programs on the same system. On Unix-like
systems, for example, the usual logic of

some_program || echo "It failed" 1>&2

would not work.

And gcc on Unix-like systems follows the usual convention of
exiting with a status of 0 for success, non-0 for failure.
(Makefiles routinely take advantage of that.)

> (And on Windows there is a special function to pick up this exit code. While
> a system() function exists (and is considerably simpler to use), it's return
> value seems unrelated to the exit code of any program it attempts to run.)


Really? I just tried an experiment on Windows 7 with
MS Visual C++ 2010 Express (compiling C code, not C++).
It seems to indicate that the result returned by system()
is exactly the same as the value passed to exit() by the
called program -- which agrees with Microsoft's documentation:
http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx

Though there is a note that says "This API cannot be used in
applications that execute in the Windows Runtime".

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-16-2013
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:


>> Sometimes I need to return two values (usually 1 for success, 0 for
>> failure;
>> the opposite of above); sometimes three or four (an exit code from an
>> editor
>> for example that may contain a request to compile the result).


> If you need two return values denoting success and failure, you should
> use 0 and EXIT_FAILURE, respectively, or EXIT_SUCCESS and EXIT_FAILURE.


Maybe I can do that, and reverse the two after the value has been retrieved.
That's if I can use the (to me) counter-intuitive values in the first place
(I always use an actual 1 or 0).

>> (And on Windows there is a special function to pick up this exit code.
>> While
>> a system() function exists (and is considerably simpler to use), it's
>> return
>> value seems unrelated to the exit code of any program it attempts to
>> run.)

>
> Really? I just tried an experiment on Windows 7 with
> MS Visual C++ 2010 Express (compiling C code, not C++).
> It seems to indicate that the result returned by system()
> is exactly the same as the value passed to exit() by the
> called program -- which agrees with Microsoft's documentation:
> http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx


So it does. I must have read those docs too carefully (they mention nothing
of exit codes), together with some presumably flawed tests. Even gcc is
giving a 0 or 1 (but again, to me, back-to-front) result.

Perhaps I can make more use of system() then, since that is more portable.

--
Bartc


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-16-2013
"BartC" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:
>>> Sometimes I need to return two values (usually 1 for success, 0 for
>>> failure; the opposite of above); sometimes three or four (an exit
>>> code from an editor for example that may contain a request to
>>> compile the result).

>
>> If you need two return values denoting success and failure, you should
>> use 0 and EXIT_FAILURE, respectively, or EXIT_SUCCESS and EXIT_FAILURE.

>
> Maybe I can do that, and reverse the two after the value has been retrieved.
> That's if I can use the (to me) counter-intuitive values in the first place
> (I always use an actual 1 or 0).


My advice: get used to the fact that Unix commands (and, I think,
many Windows commands as well) return a status of 0 for success,
non-0 for failure.

The reason is that there's typically only one way for a program to
succeed, and many ways for it to fail. The status result can (in an
ad hoc way) provide more information about the nature of the failure.

There's no real need to convert the 0=success, non-0=failure value to
something you find more intuitive. Just think of it as a status code,
not a Boolean. To test whether a program succeeded or failed:

if (system("...") == 0) {
/* success */
}
else {
/* failure */
}

>>> (And on Windows there is a special function to pick up this exit
>>> code. While a system() function exists (and is considerably simpler
>>> to use), it's return value seems unrelated to the exit code of any
>>> program it attempts to run.)

>>
>> Really? I just tried an experiment on Windows 7 with
>> MS Visual C++ 2010 Express (compiling C code, not C++).
>> It seems to indicate that the result returned by system()
>> is exactly the same as the value passed to exit() by the
>> called program -- which agrees with Microsoft's documentation:
>> http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx

>
> So it does. I must have read those docs too carefully (they mention nothing
> of exit codes), together with some presumably flawed tests. Even gcc is
> giving a 0 or 1 (but again, to me, back-to-front) result.
>
> Perhaps I can make more use of system() then, since that is more portable.


"More portable" meaning, in this case, that it works reasonably on
Unix-like and Windows-like systems (though the Unix return value is more
complicated). If that's portable enough for you, great. But IMHO it's
important to be aware that the C standard doesn't say much about the
meaning of the value returned by system(), or about its relationship, if
any, to the value passed to exit(). The behavior could be quite
different on other systems.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      02-16-2013
Keith Thompson <(E-Mail Removed)> wrote:
> "BartC" <(E-Mail Removed)> writes:


(snip)
>> Maybe I can do that, and reverse the two after the value has been retrieved.
>> That's if I can use the (to me) counter-intuitive values in the first place
>> (I always use an actual 1 or 0).


> My advice: get used to the fact that Unix commands (and, I think,
> many Windows commands as well) return a status of 0 for success,
> non-0 for failure.


I first knew return codes from OS/360, where they are usually mutliples
of four, but otherwise 0 is usually success, 4 a little worse
(warning), 8 is about what is usually called error (returned by
compilers that could keep compiling, at least for syntax checking),
then 12 for fatal errors (the compiler gave up), and 16 even worse
(such as the inability to open SYSPRINT, what some might call stdout).

> The reason is that there's typically only one way for a program to
> succeed, and many ways for it to fail. The status result can (in an
> ad hoc way) provide more information about the nature of the failure.


> There's no real need to convert the 0=success, non-0=failure value to
> something you find more intuitive. Just think of it as a status code,
> not a Boolean. To test whether a program succeeded or failed:


But this is comp.lang.c where booleans are int.

It does confuse things like the tests in csh, where success is 0,
and apply to the && and || operators.

(Which are supposed to work like C operators.)

-- glen
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-17-2013
On 02/16/2013 05:46 PM, glen herrmannsfeldt wrote:
....
> But this is comp.lang.c where booleans are int.


_Bool b = 3;

The resulting value of 'b' does not quite fit your description.
--
James Kuyper
 
Reply With Quote
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      02-17-2013
On Sat, 16 Feb 2013 20:10:14 +0000, BartC wrote:

>
> Maybe I can do that, and reverse the two after the value has been
> retrieved. That's if I can use the (to me) counter-intuitive values in
> the first place (I always use an actual 1 or 0).
>

Would it still be counter-intuitive if you regard the result of an
application not as a boolean, but as a status code (with 0 == "success",
EXIT_FAILURE == "generic failure", other values more specific failure
codes)?
Or do you then also use 1 for success and several values of 0 to indicate
the various failures?

Bart v Ingen Schenau
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      02-17-2013
In article <kfqv4k$ddo$(E-Mail Removed)>,
Bart van Ingen Schenau <(E-Mail Removed)> wrote:
>On Sat, 16 Feb 2013 20:10:14 +0000, BartC wrote:
>
>>
>> Maybe I can do that, and reverse the two after the value has been
>> retrieved. That's if I can use the (to me) counter-intuitive values in
>> the first place (I always use an actual 1 or 0).
>>

>Would it still be counter-intuitive if you regard the result of an
>application not as a boolean, but as a status code (with 0 == "success",
>EXIT_FAILURE == "generic failure", other values more specific failure
>codes)?
>Or do you then also use 1 for success and several values of 0 to indicate
>the various failures?


The core problem underlying all of this - is the fact that the shell treats
a return value of 0 as "TRUE" and anything else (i.e., non-zero) as FALSE.
Which is the exact opposite of what C (and most other programming languages)
do. Hence the confusion. Digging further, what underlies that is a basic
intuitive feeling that "TRUE" should be "good" and FALSE "bad", which, I
think, corresponds with most people's basic feelings about the Universe.

Interestingly enough, the first platform I ever used that used the concept
of TRUE/FALSE to indicate error/success, did so in that order - namely,
TRUE == error and FALSE == success. Counterintuitive this was, but it got
the job done nicely.

Finally, note that the Windows API mostly follows the model that 0 == failure,
1 (although this is usually documented as "non-zero") == success, because
this is what most people (unless they've come from a Unix background) expect
and are comfortable with, even though it is technically less efficient.

Since it is clear that "BartC" comes from a Windows background, it seems
reasonable to assume that that explains why he is more comfortable with the
Windows model.

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-17-2013
Bart van Ingen Schenau <(E-Mail Removed)> writes:

> On Sat, 16 Feb 2013 20:10:14 +0000, BartC wrote:
>
>>
>> Maybe I can do that, and reverse the two after the value has been
>> retrieved. That's if I can use the (to me) counter-intuitive values in
>> the first place (I always use an actual 1 or 0).
>>

> Would it still be counter-intuitive if you regard the result of an
> application not as a boolean, but as a status code (with 0 == "success",
> EXIT_FAILURE == "generic failure", other values more specific failure
> codes)?
> Or do you then also use 1 for success and several values of 0 to indicate
> the various failures?


It may be a bit off the wall, but this always makes me think of the
opening of Anna Karenina:

"Happy families are all alike; every unhappy family is unhappy in its
own way."

Information is only needed to record the result of an unhappy program.

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments