On 13.12.2018 14:15, Johan Corveleyn wrote:
> On Wed, Dec 12, 2018 at 10:23 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Stefan Kueng wrote on Wed, 12 Dec 2018 21:16 +0100:
>>> And as I repeatedly said: TSVN does validate the input as good as it
>>> can. But if svn does neither describe the *exact* specs in the docs nor
>>> provide any APIs that do that, then TSVN has to guess.
>>> And no: specifying that paths/uris have to be "canonicalized" is not
>>> enough because I do that, using the svn APIs.
>>> So apparently that's not enough.
>> Stefan, there is nothing we can do with this information. If you have
>> found a value for which svn_foo_is_canonical(svn_foo_canonicalize(value))
>> returns false, please tell us what that value is.
> Just thinking out loud here, but could we perhaps log the
> non-canonical value as part of the assertion output?
> Instead of:
> line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> something like
> line 10238: assertion failed
> That way, we would at least have some concrete information ...
There's no "logging" involved, the text comes from the expansion of the
assert() macro (or SVN_ERR_ASSERT_NO_RETURN), which can only show you
the assertion expression, not the values of the variables involved.
The only way to do that would be to change all those places to return
errors instead, and that would involve massive API churn.
An alternative would be to introduce new canonicalization wrapper
functions with the signature:
svn_xxx_canonicalize_safe(xxx_t **canonical, const xxx_t *original,
and these would perform the svn_xxx_is_canonical check internally. TSVN
would still have to upgrade to using the new functions to canonicalize
stuff before calling our other APIs. And of course nothing has been
stopping TSVN from using such canonicalization wrappers already; these
new functions would just be public wrappers around existing public
Received on 2018-12-13 14:26:28 CET