On Mon, Apr 23, 2012 at 11:01 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Bert Huijben wrote:
>
>> you could just use
>> assert(svn_relpath_is_canonical(base_relpath)); for a debug only check. (or
>> SVN_ERR_ASSERT() if you also want to slow down release versions)
>
> The policy is: always use 'SVN_ERR_ASSERT' rather than 'assert' (in functions that return svn_error_t).
>
> Of course he doesn't "want to slow down" Subversion.
>
> The choice between 'assert' and 'SVN_ERR_ASSERT' should be based on whether we want an application program to be able to catch such a failure. We long ago decided that the answer is YES we do want to write our library functions in such a way that an application can catch an assertion failure if its author chooses to do so. SVN_ERR_ASSERT was introduces to fulfil that need.
>
> There isn't currently an easy build switch (such as NDEBUG) to disable SVN_ERR_ASSERT completely at compile time. That's just a side issue. If you want such a switch, just ask; we can easily create one. Or if you think we need two levels of assertions -- one for quick tests and another for slow tests -- and want to be able to compile-out the slow ones independently of the quick ones, just ask. But implying we should use 'assert' for slow tests and 'SVN_ERR_ASSERT' for quick tests is the Wrong Way.
For what it's worth, I often just define SVN_ERR_ASSERT() to assert()
so as to make running through the debugger a bit easier.
I think Bert's main argument was that our "heavy" (so-called)
assertion system is in place during release and production builds,
which could have negative performance implications in those systems.
It isn't a question of how fasts the tests run, but how fast our final
product runs.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-23 18:22:46 CEST