Path: utzoo!mnetor!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: optimizing assert
Message-ID: <2300@haddock.ISC.COM>
Date: 17 Jan 88 19:50:50 GMT
References: <11295@brl-adm.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 25

In article <11295@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>In article <2276@haddock.ISC.COM> Karl Heuer <karl@haddock.ISC.COM> writes:
>>Subproposal A: ... assert() shall always evaluate its argument ...
>
>Doesn't this defeat the purpose of NDEBUG?  ... The expression evaluation
>code would [still be generated].

If the expression has side effects, I think it's clear that the user does want
them to be evaluated.   If the expression has no side effects, the compiler is
free to generate zero instructions.  (I realize that there are some pretty bad
nonoptimizing compilers out there.  I wish there were fewer.)

>>Subproposal B: The macro shall expand into a void expression.  [To guarantee
>>that it is legal in an expression context.]
>
>I may be missing something here, but I don't see where it makes much
>difference what type `assert' expands to.

The intended emphasis was on "expression", not "void".  Some implementations
currently expand assert() into nothing at all (when NDEBUG is set) and/or a
non-expression statement (when NDEBUG is unset).  As for the type, since the
synopsis says "void assert(int)", why not require the implementation to
enforce it?  All it takes is a (void) cast, and it catches more errors.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint