Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!dsill@NSWC-OAS.arpa
From: dsill@NSWC-OAS.arpa (Dave Sill)
Newsgroups: comp.lang.c
Subject: Re: optimizing assert
Message-ID: <11295@brl-adm.ARPA>
Date: 15 Jan 88 20:42:28 GMT
Sender: news@brl-adm.ARPA
Lines: 31

In article <2276@haddock.ISC.COM> Karl Heuer <karl@haddock.ISC.COM> writes:
>Subproposal A: Whether or not NDEBUG is set, assert() shall always evaluate
>its argument for side effects.

Doesn't this defeat the purpose of NDEBUG?  Granted, the
diagnostic-generating code would be left out, but the expression
evaluation code would remain.

>Subproposal B: The macro shall expand into a void expression.
>
>Rationale: This would guarantee that it is legal in an expression context,
>e.g. "y = 1.0 / (assert(x!=0.0), x)".  This isn't critical, but it helps
>prevent surprising behavior in some contexts.

I may be missing something here, but I don't see where it makes much
difference what type `assert' expands to.  The example would work if
it expanded to an `int'.

>Subproposal C: If the argument of assert() is true (compares unequal to zero),
>then the macro returns no value.  Else, if the NDEBUG macro is not defined,
>then a message is printed and the abort() function is invoked.  (At this point
>we still agree with the dpANS; the next statement is the proposal.)
>Else, [assertion is false and NDEBUG is defined,] behavior is undefined.

I like this.  After all, the assertion is false...

========
The opinions expressed above are mine.

"Damn it, wine is liquid food!"
					-- Robert Mondavi