Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Aborting

Reply
Thread Tools

Aborting

 
 
Stefan Ram
Guest
Posts: n/a
 
      01-18-2010
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()

?

 
Reply With Quote
 
 
 
 
Lew Pitcher
Guest
Posts: n/a
 
      01-18-2010
On January 18, 2010 15:27, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de 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. ------


 
Reply With Quote
 
 
 
 
Ben Pfaff
Guest
Posts: n/a
 
      01-18-2010
(E-Mail Removed)-berlin.de (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
 
Reply With Quote
 
frank
Guest
Posts: n/a
 
      01-19-2010
Lew Pitcher wrote:
> On January 18, 2010 15:27, in comp.lang.c, (E-Mail Removed)-berlin.de 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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-19-2010
frank <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      01-19-2010
On 19 Jan, 05:33, frank <(E-Mail Removed)> wrote:
> Lew Pitcher wrote:
> > On January 18, 2010 15:27, in comp.lang.c, (E-Mail Removed)-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?)
 
Reply With Quote
 
Ersek, Laszlo
Guest
Posts: n/a
 
      01-19-2010
In article <(E-Mail Removed)>, frank <(E-Mail Removed)> 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
 
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


Similar Threads
Thread Thread Starter Forum Replies Last Post
.NET Timers aborting in web application Jeff Greenland ASP .Net 3 12-18-2003 08:12 PM
Re: Aborting a _Click event? Wayne MJ ASP .Net 2 07-29-2003 05:37 AM
Aborting a _Click event? Wayne MJ ASP .Net 0 07-23-2003 05:50 AM
Aborting Fucntions Willem Oosthuizen VHDL 2 07-11-2003 11:32 AM
I need help on aborting msxml3 sax2 parser Asana MCSD 0 06-30-2003 01:02 PM



Advertisments