On 08.03.2013 09:23, Ben Reser wrote: > On Thu, Mar 7, 2013 at 11:47 PM, Branko Čibej <[email protected]> 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
