Christian Stork wrote:
> On Thu, Feb 16, 2006 at 03:17:02AM +0100, Branko Čibej wrote:
>
> The reason why QA is done with disabled assert()s is that assert()s
> could be very inefficient and performance is certainly part of the Q
> that is being A'ed. Another reason why assert()s shouldn't be in the
> final product is that the assert()s proper could be incorrect (this
> happened much more often to me than I would have expected) and you don't
> want your final product crash because of a false assert.
>
Um. What you call a "require()" could also be incorrect. I fail to see
the difference between assert() and require() here.
That's the main reason to test stuff -- because bits could be incorrect. :)
>> Furthermore it's quite likely that a bug reported against the release
>> version can't be reproduced in the debug version.
>>
>
> How can this be if assertions don't have side-effects? Are you talking
> about timing issues? If so, tough luck. The bug needs to be debugged
> without assert()s enabled.
>
Even if an assert has no side effects, disabling it could expose a
different bug, by allowing code to execute that would never have been
reached while the assert is active.
This is one of the QA nightmare scenarios:
QA: Hey, we found a bug in the release bits. Here's the repro.
Dev: Sorry, can't reproduce your error, I hit an assert as expected.
QA: So test the release version!
Dev: Uhuh. We don't do that.
>> This debug- vs. release-mode dichotomy comes from the commercial world
>> and its paranoia about reverse engineering. Here, we *like* reverse
>> engineering.
>>
>
> I have no idea where this comes from. Can you give some more details?
> I don't know anything about real-world reverse engineering but I'm not
> sure that "effectless" assertion code might not even confuse the reverse
> engineer.
>
Another common difference between debug and release versions is that the
latter doesn't contain debug information.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 21 10:49:54 2006