On 24.12.2011 18:32, Stefan Küng wrote:
> On 24.12.2011 18:18, Branko Čibej wrote:
>> On 24.12.2011 17:37, Daniel Shahaf wrote:
>>> Stefan Küng wrote on Sat, Dec 24, 2011 at 17:24:51 +0100:
>>>> Then why are there multiple statements like this in the svn code:
>>>> SVN_ERR_ASSERT_NO_RETURN(svn_dirent_is_absolute(local_abspath));
>>>> (example from libsvn_wc\util.c, line 197).
>>> Because the containing function doesn't return svn_error_t.
>>
>> Which is exactly what I said earlier. As long as we have /any/ function
>> that does not return an error code, unless we can prove that it cannot
>> fail in a detectable manner, there's not even a theoretical chance of
>> removing such assertions.
>
> But that function doesn't need an absolute path at all. Callers of
> that function might, but those functions could most likely return an
> error.
>
> and please take a look at the file libsvn_wc\props.c, search for
> SVN_ERR_ASSERT_NO_RETURN.
> I don't even know how to respond to something like this: calling
> SVN_ERR_ASSERT_NO_RETURN() but in the very next line there's a
> statement that could return an error, just that it never goes there
> because SVN_ERR_ASSERT_NO_RETURN as the name implies never returns.
>
> I can't add anything more to code like this.
Stefan, stop pointing fingers at implementation issues. You have commit
access, so you can fix that kind of abuse of aborts yourself instead of
blaming "subversion." Granted that these constructs are being abused in
the code, just sitting back and yammering on the list and then being
offended when you don't get immediate results isn't helping anyone.
My point is that you are never going to get rid of aborts. You can
certainly reduce their number, which is already happening. But even that
is going to become increasingly difficult.
It's perfectly OK to raise these issues on the dev@ list. It's not OK to
imply that the volunteers who built Subversion are a bunch of
incompetents just because you found some bugs in the code. It doesn't
matter how long those bugs have been there.
Don't make me go and review your TSVN code for the same kind of
silliness. :)
-- Brane
Received on 2011-12-25 06:59:39 CET