> -----Original Message----- > From: Julian Foad [mailto:julianf...@btopenworld.com] > Sent: maandag 23 april 2012 18:02 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Always use SVN_ERR_ASSERT [was: svn commit: r1329234 - in > /subversion/trunk: ./ subversion/libsvn_delta/compat.c] > > 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).
No, we also use assert in several places, e.g. in all path processing functions. assert() isn't evaluated when NDEBUG is specified. In that case the argument is ignored. SVN_ERR_ASSERT() and SVN_ERR_ASSERT_NO_RETURN() *are* evaluated in release builds. Bert > > 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. > > - Julian