asserts and unexpected returns (was: Re: Assert)

[Dave Burton]

[ I'm ignoring advice from the adage "Never argue with a fool." ]
[ But this is the last time :-) ]

In article <4093 at awdprime.UUCP> daveb at bach.austin.ibm.com (Dave Burton) writes:
# The only way to put an exit() after a failing assert() is to
# rework the macro, which is not portable.

In article <18662 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
| you put a conditional.  then you put an exit.  this gives you
| a conditional exit statement.  most programmers don't have
| trouble with this.  many of them even write code like
| 
| 	if (! (chunk = malloc (sizeof *chunk))) {
| 		perror ("oops");
| 		exit (1);
| 	}
| 
| how about (gee, just a suggestion, i normally charge for my
| programming lessons, so this isn't a programming lesson)
| 
| 	if (! (chunk = malloc (sizeof *chunk))) {
| 		perror ("oops");
| 		assert (chunk != 0);
| 		exit (1);
| 	}
| 
| now, i'd never actually do this, so don't think i am advocating
| this exact code fragment.  but gee, dave, it isn't that hard.

If this is your idea of "programming lessons", I hope your charge
is that nobody reveals you taught them.  You're nobody's teacher
(especially after this thread) and not my "Uncle Fred".
Lose the flippant 'tude, dude, and get back to reality.

Your example is ludicrous.  Of what use would assert be in such a case?
Then you disclaim your example with "now, i'd never actually do this".
Why did you give this example then?  If you have a clear idea how to
do what you propose, show us.

#|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.

I ignored this the first time around:
The System V Programmer's Reference Manual also does not include
namei() or major(), does this mean they're not there, or can't be
relied upon in kernel code?

| hmmm.  no ASSERT (or assert) in my <sys/debug.h>.  perhaps this really
| is just another IBMism.  perhaps this is implementation specific ...

SVR2.1 has it.  My SVR3.2 (ESIX) has it.  I've used it in AT&T's SVR3.2
i386 and 3b2 offerings.  I'd say it's not an IBMism, nor is it implementation
specific.  The UNIX SVR3 BCI Driver Development Guide documents it quite well.
See pp 13:13,14 for a discussion.  It's also quite well known to SV
kernel hacks.

| furthermore, i don't recall any requirement in any of the documentation
| i've read requiring assert() invoke _assert() or assfail() or any of
| the stuff you keep talking about.

Nobody ever said there was.  I mentioned _assert() and assfail()
simply to enlighten you, since you didn't seem to understand about the
macro nature of assert(), and couldn't find ASSERT/assert in your kernel's
namelist.  It was never mentioned in the context of portability except
to elucidate why various assert() "band-aids" were not portable.

# I admit, I did look at the sources to verify my understanding
# before posting to the net.  That's generally considered wise.
# Perhaps you would fare better if you did the same.

| are you in the habit of violating your non-disclosure agreements
| with IBM and AT&T just so you can make your postings?  many of the
| people in this group have access to source code as well, but most
| of us don't run off and read it then report what we find to the
| net.

I certainly didn't "run off and read it then report what [I found] to the net."
It was more like:  "Hmm.  I think John is wrong.  I've used assert()
before, and it never returns.  Perhaps it's only that way on BSD and SVRx
systems.  Before I post,  I'd better confirm with other implementations."

Possibly the only "trade secret" I revealed was that IBM's abort() can
be trusted to not return.  That's positive press.  But go ahead, forward
my posting(s) to my management and IBM security (as if they haven't
already screened them) and let's see who gets their hand slapped.

| just so you get to see how this =really= works in the =real=
| world, try this -
| [ paraphrase of the demo program I wrote to show John's folly ]

Grrrr!  This really pisses me off, John.  I _know_ what that program does.
If you really want to brow-beat me, modify it to make the assert() _always_,
_portably_ exit, without repeating the test in the assertion itself
(which you were already flamed for once).
--
Dave Burton
inet: daveb at bach.austin.ibm.com
uucp: cs.utexas.edu!ibmchs!auschs!nostromo!daveb