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.
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.
Thoughts?
Daniel
On 26 October 2015 at 02:28, Daniel Santos daniel.santos@pobox.com wrote:
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.
Thoughts?
I'd put something like that inside an ERR_ON block.
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@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
On 10/26/2015 09:31 AM, Michael Stefaniuc wrote:
I guess you'll have to show that the assert() has a real impact in an application. Else it doesn't matters.
I think the question should be the other way around, asking first "is this check/assert needed?" rather than later "should we get rid of this check/assert?". If a check is only needed at certain times (i.e. when developing around the code), then you can get rid of it when it's not those times. One assert() may be imperceptible, but hundreds or thousands sprinkled around the code base can cause execution to be slow in general with no specific choke point.
On 10/26/2015 09:51 PM, Chris Robinson wrote:
On 10/26/2015 09:31 AM, Michael Stefaniuc wrote:
I guess you'll have to show that the assert() has a real impact in an application. Else it doesn't matters.
I think the question should be the other way around, asking first "is this check/assert needed?" rather than later "should we get rid of this check/assert?". If a check is only needed at certain times (i.e. when developing around the code), then you can get rid of it when it's not those times. One assert() may be imperceptible, but hundreds or thousands sprinkled around the code base can cause execution to be slow in general with no specific choke point.
You've removed the context but I was strictly referring to the case that he mentioned that the assert() is useful to have but it would be too expensive to use just a plain assert().
I'm too the opinion that code with too many assert()s sprinkled in is unfinished code and shouldn't go in as is. Of course it can go into Staging that way. But even in that case you want a plain assert() and not a wrapper that is disabled for users., User feedback is an important part of the development process.
And last but not least, IMHO, crashing is the far better response than silently corrupting user data. So yes, using -NDEBUG is misguided.
bye michael
On 10/26/2015 03:31 PM, Michael Stefaniuc wrote:
I'm too the opinion that code with too many assert()s sprinkled in is unfinished code and shouldn't go in as is. Of course it can go into Staging that way. But even in that case you want a plain assert() and not a wrapper that is disabled for users., User feedback is an important part of the development process.
The asserts are used for development, and are no longer needed for a proper release. The problem comes with something like Wine where you have a large code base with developers that come and go over time. So one developer finishes what they're doing and no longer needs the asserts, but someone else comes along later to work on the code and could use those asserts (but wouldn't know to put them in).
I've also found asserts to be useful for static analysis. Where you know something will be true because other code has already made sure of it, but analysis of the function reports a problem. The assert clears away that false-positive, but checking it at runtime is wasteful and unnecessary, especially for release builds.
And last but not least, IMHO, crashing is the far better response than silently corrupting user data. So yes, using -NDEBUG is misguided.
Not all uses of debug checks are necessary for release builds (IMHO, if you need most/all of your debug checks in a release build, perhaps it's not ready for release). In such cases there's no danger of corrupt data or crashing, but during future development there may be. Using -DNDEBUG is no more misguided than not using -D_DEBUG. In both cases, you're saying you don't need those debugging features.
FWIW, I've also desired a variant of assert() that doesn't get compiled out in release builds, since assert() does by default, but that doesn't mean I want all assert()s to stay in release. Having variants of assert where one stays and another goes away for release would be useful. It's a shame some distros have taken it upon themselves to determine whether NDEBUG is used or not, since now developers like me can't know how a standard function like assert() will behave in release.
-
Chris Robinson -
Daniel Santos -
Henri Verbeet -
Michael Stefaniuc