Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Checking Exit Codes
Message-ID: <18689@rpp386.cactus.org>
Date: 4 Nov 90 00:32:22 GMT
References: <18647@rpp386.cactus.org> <4057@awdprime.UUCP> <18658@rpp386.cactus.org> <4430@segue.segue.com> <18664@rpp386.cactus.org> <4447@segue.segue.com>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 25
X-Clever-Slogan: Recycle or Die.

In article <4447@segue.segue.com> jim@segue.segue.com (Jim Balter) writes:
>In the normal use of assert, the code following the assert is executed under
>normal conditions.  The examples you give are simply not real uses of assert.
>Assert is not intended to be used to print error messages, as you seem to use
>it in your malloc example.  A reasonable use is something like

as i said, it was a fake example.  you pay your money, you take your chances.

i typically don't use assert, for exactly the reasons i've mentioned.  if i
want a core dump, i write "abort()".  if i want an error message, i use
perror or fprintf.  but i have found assert to vary from machine to machine
enough to be useless.  on one system, it may core dump.  on another, it
exits with no core dump ever.  on yet another it always exits even if you
ignore the signal and keep it from dumping core.  on still yet another you
can't ignore or catch the signal and it always dumps core (and always exits).
so, describe the exact behavior of assert() without reference to a standards
document.

as another poster wrote, it appears that ANSI C (yes, i've had my eyes
checked lately ;-) specifies that abort() can't return.  this is good news.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson