Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!cello!reed!d75!awdprime!nostromo.austin.ibm.com!daveb From: daveb@nostromo.austin.ibm.com (Dave Burton) Newsgroups: comp.unix.internals Subject: Re: asserts and unexpected returns (was: Re: Assert) Message-ID: <4157@awdprime.UUCP> Date: 8 Nov 90 17:56:47 GMT References: <18647@rpp386.cactus.org> <4057@awdprime.UUCP> <18658@rpp386.cactus.org> <4093@awdprime.UUCP> <18662@rpp386.cactus.org> Sender: news@awdprime.UUCP Reply-To: daveb@bach.austin.ibm.com (Dave Burton) Organization: IBM AWD, Austin, TX Lines: 99 [ I'm ignoring advice from the adage "Never argue with a fool." ] [ But this is the last time :-) ] In article <4093@awdprime.UUCP> daveb@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@rpp386.cactus.org> jfh@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 . 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@bach.austin.ibm.com uucp: cs.utexas.edu!ibmchs!auschs!nostromo!daveb