Checking Exit Codes (was: Re: Trojan Horses)

[John F. Haugh II]

In article <4057 at awdprime.UUCP> daveb at bach.austin.ibm.com (Dave Burton) writes:
>In article <18647 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>No, John.  The intent of assert() is that it compile away to nothing
>in the presence of NDEBUG, without the baggage of #ifdef/#endif blocks.
>The design of assert() is that it behave as a null statement when the
>assertion is true, otherwise it should abort() the program.

so, you will always assume that failing asserts never return?  this
means that your portable programs aren't.  accepting the statement
that assert() returns control to your program in strange and unexpected
ways only requires that you pay careful attention to the placement
of your assert() statements, whereas rejecting this statement may
lead to strange problems if you have an assert() with the SIGIOT
signal ignored or caught.

you could splatter your code with feature test macros for each
and every one of those versions you listed, with special behavior
to be followed.  or you could take the easy way out, listen to
your uncle fred, and just put an exit after failing assert()
calls.  this is easy, portable, and foolproof.  it has the novel
property that it always works.

>                                                             This also
>corresponds nicely to the kernel functionality of assert() - it panic()s.

that may be true - but the kernel assert() function is not defined
in the System V Programmer's Reference Manual sitting next to me.
i checked the namelist on the kernel running here.  no assert.  hmmm.
perhaps this is another IBMism?  always assume the worst; never
count on undocumented behavior or nonstandard features.

the point of this article was to illustrate that ignoring unexpected
returns can lead to unexpected results, not to serve as an
oppurtunity for someone to research every version of assert().

close() may return an error.  assert() may return on failure.  this
is how you write robust code.  you can argue if catching strange
returns is worth it, or you can sit back and count your bug reports.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson