assert, NDEBUG and you

Michael Stefaniuc mstefani at
Mon Oct 26 11:31:44 CDT 2015

On 10/26/2015 02:28 AM, Daniel Santos wrote:
> I had been going through life assuming that people who build software
> for release generally use some variant of -march=<something generic> -O2
> -DNDEBUG. Not only was I wrong, but Debian now considers NDEBUG "EBW
> <>" (which I've
> learned means "Evil Bad Wrong
> <>") and
> strips it even from cmake builds (which define it by default for release
> builds). From what I can tell, this is a common practice and it means
> that those asserts that I love to liberally saturate my sources with
> (even in hot spots) are bloating my code at release.
Well, Wine has the same stanza on that, for almost 10 years now:

commit 6d9af55a120df781f69e919bad05e35c813d0dbe
Author: Mike McCormack <mike at>
Date:   Mon Apr 17 18:17:18 2006 +0900

    configure: Remove the --disable-debug and --disable-trace options.

> In light of this, I'm thinking that we may need a standard wine macro
> for asserts that we *really* only want when we're making changes and
> debugging and are activated by -DDEBUG or some such. Many of the asserts
> I use aren't something that I would ever expect to fail after
> development and testing is completed and shouldn't be in release, but
> can fail when me or somebody else makes a change or uses the function
> incorrectly. Hot code paths and inline functions are other examples of
> where such an assert would be useful when developing, but we would not
> want to pay for it in a release build.
I guess you'll have to show that the assert() has a real impact in an
application. Else it doesn't matters.


More information about the wine-devel mailing list