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
