From: Michael \(michka\) Kaplan (email@example.com)
Date: Sun Mar 27 2005 - 12:51:41 CST
Ok, I guess a test that has at least two characters no matter what the form
was (so that the target did not always start at the same 0th index as the
source would help here.
Though since that is more of a code bug than a conformance to proper
transformation bug, it is not really what the tests are about. If the author
preferred to instead clarify the purpose of the tests I would not find their
position to be unsupportable....
----- Original Message -----
From: "Elliotte Rusty Harold" <firstname.lastname@example.org>
To: "Michael (michka) Kaplan" <email@example.com>
Sent: Sunday, March 27, 2005 6:36 AM
Subject: Re: Additional normalization test cases
> Michael (michka) Kaplan wrote:
> > What was the bug you fixed? It might be easier to figure out a good way
> > add test cases by knowing what the implementation was doing....
> The specific bug involved an off-by-one error indexing into the string
> in the composition step. Specifically, I was assuming the index into the
> source string could also serve as an index into the result string, and
> that turned out not to be the case. The result was that it recomposed
> into Ä„L. I could successfully normalize the single characters Ä˝ or Ä„. It
> was the combination of the two in succession that triggered the bug.
> What was really surprising was that I could pass all the Unicode
> supplied tests and still miss this. This may be because of the naivete
> of my algorithm, which is much less sophisticated than the standard
> Unicode implementation. In particular, it does not (yet) notice that the
> string Ä„Ä˝ is already in NFC which many implementations might do, and
> thus never check something like this in the first place.
> Elliotte Rusty Harold firstname.lastname@example.org
> XML in a Nutshell 3rd Edition Just Published!
This archive was generated by hypermail 2.1.5 : Sun Mar 27 2005 - 12:51:10 CST