On 08.03.2013 09:23, Ben Reser wrote:
> On Thu, Mar 7, 2013 at 11:47 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> Tend to agree but I'd restrict such checking to the APIs we consider
>> "public" -- regardless of whether or not they're exposed in the public
>> headers or not. Doing such checks in every layer is definitely overkill.
> I'd like to agree but the way our APIs are layered and actually used
> is not conducive to this.
>
> Case in point...
>
>> Furthermore, while your patch proposes checks on the FS vtable level, I
>> believe servers are supposed to use the svn_repos APIs and it would
>> therefore make sense to make those bullet-proof (svn_fs should only be
>> used directly by the admin utilities).
> Yes the servers are supposed to be using svn_repos APIs. However,
> they end up needing to use svn_fs APIs because the repos layer
> provides an svn_fs_t and some of the features of the the libsvn_fs
> layer are not provided via the repos layer. E.G. it's impossible to
> retrieve the text of a file with libsvn_repos.
Yes, I know. :(
I keep thinking we never should have invented a separate svn_repos layer
with wrappers for 80% of svn_fs. But that's crying over spilt milk.
> We could go through and figure out which bits of the various layers
> are used by the servers. But I'm not sure how much work that would
> actually be.
A lot.
So current candidates are svn_repos and svn_fs; but what about the
varioius svn_subr API groups? Retrofitting parameter checks all over the
place there seems like quite a bit of extra work, too.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-03-08 09:47:19 CET