W3C home > Mailing lists > Public > www-archive@w3.org > April 2003

Re: cwm uripath.py bug

From: Ryan Lee <ryanlee@w3.org>
Date: Thu, 3 Apr 2003 17:35:45 -0500 (EST)
To: Dan Connolly <connolly@w3.org>
cc: <www-archive+n3bugs@w3.org>, Tim Berners-Lee <timbl+n3bugs@w3.org>
Message-ID: <Pine.LNX.4.30.0304031727490.25190-100000@tux.w3.org>

On second thought, the code needed another if case.  Added a test case to
exercise:

 refTo("http://example/x/abc.efg", "http://example/x/")

should return

 "./"

which it now does (in the context of below, that would have caused Python
to barf; the original 'fix' would have returned an empty string).

On 3 Apr 2003, Dan Connolly wrote:
> nice work; I'm reviewing the work, but it's hard for
> me to think about it wihout seeing the test case.
>
> Did you add a unit test to be sure we don't break this in the
> future? I don't see one.
>
>  test-before-you-code
>  http://www.w3.org/2000/10/swap/test/README
>  -> http://www.extremeprogramming.org/rules/testfirst.html
>
> On Thu, 2003-04-03 at 16:08, Ryan Lee wrote:
> > http://dev.w3.org/cvsweb/2000/10/swap/uripath.py
> >
> > A while loop at line 194 increments a string index past the end of the
> > shortest string (contrary to the comments) in the case where refTo(base,
> > uri) is comparing uneven length strings.  If uri is shorter, then code
> > like uri[i] on line 217 will complain about the index being out of bounds
> > (whereas code using splicing like line 208 will just ignore the problem).
> >
> > Fixed by checking that i<len(uri) in line 217, which I think is correct:
> > if base and uri match for the whole length of uri, then it will take some
> > number of '../' to get to uri from base, with no other trailing
> > characters (the else case).
> >
> > Passes uripath.py tests, Python no longer barfs on what I run it on -
> > checked in change.
>
>

-- 
Ryan Lee
ryanlee@w3.org
Received on Thursday, 3 April 2003 17:35:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:29 GMT