On Mon, Dec 29, 2008 at 06:35:58PM +0100, Stefan Kueng wrote:
> Stefan Sperling wrote:
> > On Mon, Dec 29, 2008 at 06:28:41PM +0100, Stefan Kueng wrote:
> >> Stefan Sperling wrote:
> >>> Then please convert all remaining asserts to either SVN_ERR_ASSERT_NO_RETURN
> >>> (for functions which do not return svn_error_t *, see r34334)
> >>> or SVN_ERR_ASSERT (for functions which return svn_error_t *).
> >> There are a lot of assert() calls left. I'm not sure whether it is safe
> >> to change all of them to SVN_ERR_ASSERT_NO_RETURN - that macro calls
> >> abort() after calling the custom handler. A simple assert() would do
> >> nothing in a release build, so changing all those to abort() doesn't
> >> seem like a good idea.
> >> I suggest changing those one by one, by those who are familiar with the
> >> code part (there are a lot in the fs_ libs, and I'm not comfortable
> >> changing those because that could lead to aborting a server).
> >
> > Nevermind, I confused assert() with abort() again, like so many
> > times before :/ It's aborts() that should be replaced by SVN_ERR_ASSERT*.
> >
> > asserts() are a different story. Since you don't like them,
> > can you suggest an alternative?
>
> Since asserts don't interfere in a release build, I'm fine with those.
OK.
> They just sometimes annoy me in a debug build - but then again, that's
> what they're there for so we can fix whatever causes the assertion.
Exactly. Because of the assertion, you found a bug, and you even fixed
it. Which is good!
> But maybe then the macro should be renamed to SVN_ERR_ABORT* instead of
> SVN_ERR_ASSERT ?
I don't think the name is wrong.
I just need to learn not to confuse abort() with assert() all the time :)
The fact that SVN_ERR_ASSERT_NO_RETURN abort()s if the handler returns
is an implementation detail that we don't need to reflect in the name.
SVN_ERR_ASSERT returns the error returned by the handler, so it does
not abort() at all, unless the handler or top-level error handlers
abort()s.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=995182
Received on 2008-12-29 18:48:35 CET