> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: maandag 23 april 2012 18:02
> To: Bert Huijben
> Cc: dev_at_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
Received on 2012-04-23 18:34:29 CEST