[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: canonicalized path hits assertion

From: Stefan Kueng <tortoisesvn_at_gmail.com>
Date: Mon, 29 Dec 2008 18:35:58 +0100

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.
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.

But maybe then the macro should be renamed to SVN_ERR_ABORT* instead of
SVN_ERR_ASSERT ?

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=995177

Received on 2008-12-29 18:36:21 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.