VK Sameer <sameer@collab.net> writes:
> OK, I'm open to suggestions :) If it helps any, the first comment is
> going to go away partially as per Philip Martin's and Peter Lundblad's
> comments.
Yeah, I think someone else suggested that simply defining what a valid
path is would do the trick (instead of detailing the algorithm for
detecting invalid ones).
> > > +svn_error_t *svn_path_is_valid_in_svn (const char *path,
> > > + apr_size_t len,
> > > + apr_pool_t *pool);
> > > +
> >
> > Judging by the signature, I'm guessing that the function returns
> > SVN_NO_ERROR if PATH is all good, and some other error otherwise. You
> > might want to state as much, so callers of the API can tell the
> > difference between an "unsupported path" error and some other error.
>
> OK, makes sense. I wasn't sure of the convention since not all functions
> seem to have the set of possible return values documented.
I'm a big fan of APIs that list every return value, but haven't the
time or energy to retroactively do this for Subversion. That said,
we are pretty good about listing return codes that we anticipate
callers explicitly testing for. I anticipate callers testing the
return value of this function (beyond just "is errorful").
In fact, since the goal of the function is to answer a question -- "Is
this path a valid Subversion path?" -- we may instead want this
interface to take an svn_boolean_t * parameter which is populated with
TRUE or FALSE to yield the answer, and leave all error conditions to
mean, "Something bad happened that prevents me from answering your
question." Besides a better semantic feel, this would also prevent
Subversion from instantiating an error that the caller might choose
not to use (and have to tear down).
> > Also, we don't generally pass lengths with our paths.
>
> I can remove that if that is the general policy.
Yep, that's the general policy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 7 03:24:30 2004