assert, NDEBUG and you

[Michael Stefaniuc]

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
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701231>" (which I've
> learned means "Evil Bad Wrong
> <https://lists.debian.org/debian-devel/2013/02/msg00351.html>") 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 codeweavers.com>
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.

bye
	michael