«

Assuming that a program is in such a desperate situation,
that one wants to abort immediatly (for example, no more
memory is available), when should one use

exit( 99 )

(where »99« is a placeholder for any possible error code) and when

abort()

?

On January 18, 2010 15:27, in comp.lang.c, wrote:

> Assuming that a program is in such a desperate situation,
> that one wants to abort immediatly (for example, no more
> memory is available), when should one use
>
> exit( 99 )
>
> (where »99« is a placeholder for any possible error code) and when
>
> abort()

I would suspect that the decision to use abort() or exit() would depend a
lot on the circumstances of the error, the goals of the application, and
the QoI of the C implementation.

abort()
- does not guarantee to flush open buffered output streams,
- does not guarantee to close open streams of any sort,
- does not guarantee to remove temporary files, and
- returns an implementation-defined "unsuccessful termination" status.

OTOH, exit()
- executes the functions registered through the atexit() function
- flushes open buffered output streams
- closes all open streams
- removes temporary files, and
- returns a program-specified exit status to the host environment

I'd use abort() only in the direst of circumstances, where the program logic
cannot guarantee the sanity of /any/ of it's data. For all other
terminations, I'd use exit().

And, I'd document the use carefully, including expected behaviour and
recovery options.

HTH
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

(Stefan Ram) writes:

> Assuming that a program is in such a desperate situation,
> that one wants to abort immediatly (for example, no more
> memory is available), when should one use
>
> exit( 99 )
>
> (where »99« is a placeholder for any possible error code) and when
>
> abort()

On Unix-like systems, abort() will often cause a core dump, but
exit() will not. It is usually much easier to find a difficult
bug with a core dump than without one, so that's part of the
criteria that I use.

Another way to look at it is that the assert macro exits by
calling abort(), so that it is appropriate to call abort() in
circumstances comparable to assertion failures.
--
Ben Pfaff
http://benpfaff.org

Lew Pitcher wrote:
> On January 18, 2010 15:27, in comp.lang.c, wrote:
>
>> Assuming that a program is in such a desperate situation,
>> that one wants to abort immediatly (for example, no more
>> memory is available), when should one use
>>
>> exit( 99 )
>>
>> (where »99« is a placeholder for any possible error code) and when
>>
>> abort()
>
> I would suspect that the decision to use abort() or exit() would depend a
> lot on the circumstances of the error, the goals of the application, and
> the QoI of the C implementation.
>
> abort()
> - does not guarantee to flush open buffered output streams,
> - does not guarantee to close open streams of any sort,
> - does not guarantee to remove temporary files, and
> - returns an implementation-defined "unsuccessful termination" status.

Is this last one synonymous with the requirement that __FILE__ and
__LINE__ be given?
>
> OTOH, exit()
> - executes the functions registered through the atexit() function
> - flushes open buffered output streams
> - closes all open streams
> - removes temporary files, and
> - returns a program-specified exit status to the host environment
>
> I'd use abort() only in the direst of circumstances, where the program logic
> cannot guarantee the sanity of /any/ of it's data. For all other
> terminations, I'd use exit().
>
> And, I'd document the use carefully, including expected behaviour and
> recovery options.

An interesting contrast, Lew. Which temporary files do you mean?
--
frank

frank <> writes:
> Lew Pitcher wrote:
[...]
>> abort()
>> - does not guarantee to flush open buffered output streams,
>> - does not guarantee to close open streams of any sort,
>> - does not guarantee to remove temporary files, and
>> - returns an implementation-defined "unsuccessful termination" status.
>
> Is this last one synonymous with the requirement that __FILE__ and
> __LINE__ be given?

What? No, it's completely unrelated.

The assert() macro writes the values of__FILE__ and __LINE__ to
stderr. There is no such requirement for abort(). And even if there
were, it would have nothing to do with the termination status.

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 19 Jan, 05:33, frank <fr...@example.invalid> wrote:
> Lew Pitcher wrote:
> > On January 18, 2010 15:27, in comp.lang.c, r...@zedat.fu-berlin.de wrote:

<snip>

> > abort()
[...]
> > *- returns an implementation-defined "unsuccessful termination" status.
>
> Is this last one synonymous with the requirement that __FILE__ and
> __LINE__ be given?

no. The "unsuccessful termination" status is some sort of indication
to the underlying OS. Typically an integer indicating failure. abort()
is not required to give file and line number. Typically it doesn't.

<snip>

> > OTOH, exit()
[...]
> > *- removes temporary files
[...]
> [...] *Which temporary files do you mean?

ones generated by the tmpfile() function (maybe others?)

In article <>, frank <> writes:
> Lew Pitcher wrote:

>> abort()
>> - returns an implementation-defined "unsuccessful termination" status.
>
> Is this last one synonymous with the requirement that __FILE__ and
> __LINE__ be given?

As others have pointed out, no. If you care about the SUS: see
WIFSIGNALED() / WTERMSIG(). Links to assert(), abort() and waitpid() in
SUSv2:

http://www.opengroup.org/onlinepubs/...sh/assert.html
http://www.opengroup.org/onlinepubs/...xsh/abort.html
http://www.opengroup.org/onlinepubs/.../xsh/wait.html

Cheers,
lacos