On 2011-12-25 06:58, Branko Čibej wrote:
> 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.
"increasingly difficult" is somehow understandable,
I (and I also guess Stefan) understands this immediately.
What I just object is declaring a bad practice/design
as good behavior/design just because it is difficult
to fix the bad practice everywhere, because this removes
the motivation to at least do it better in the future.
>
> 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 10:20:59 CET