[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: crash with incomplete url

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-05-23 21:06:10 CEST

Stefan Küng writes:
> Peter N. Lundblad wrote:
> > Malcolm Rowe writes:
> > > On Tue, May 23, 2006 at 02:51:56PM +0200, Peter N. Lundblad wrote:
> > > > My position on this is that svn_path_canonicalize should not crash fro
> > > > any string, and no library function should crash on any string
> > > > returned by svn_path_canonicalize.
> > > >
> > >
> > > Strong +1 in theory, except: what should svn_path_canonicalize() do when
> > > passed an invalid path or URL? There appears to be no way to return
> > > an error.
> > >
> > Canonicalize according to its documentation. Invalid URLs need to be handled
> > by the path functions. No one says we should crash on "hppt://foo/bar".
>
> Haven't tested that url (hppt://foo/bar) if it crashes, but if it does,
> then this proves my point:
> a client can't check if this url is valid or not. Because it *is* a
> valid url according to the specs, but Subversion doesn't recognize the
> protocol? How would a client know that? For example, a user could add a
> separate sub-protocol in the config files (e.g. svn+myencryption).
> Should a client parse those files and see if maybe Subversion can handle
> it? I don't think so, because that would mean a lot of
> checking/configfilereading/stringparsing is done twice which is unnecessary.
>
I think you missed my point. My point was to say that this should *not* crash.

In general, I think we should try to not crash on say, invalid urls and paths.
Canonical paths is a special case, because it has a specific meaning and we
provide a function for it in the APIs.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 23 21:07:33 2006

This is an archived mail posted to the Subversion Dev mailing list.