Hello!
I guess I encountered a bug in the MinML parser:
When the parser checks for endCDATA, it will check for two ']'
followed by a '>'. If that is not the case it will write 3 characters,
the two '>' and the offending character to the buffer. In that state
it might overwrite the next characters to read.
As an example consider the sequence "]]+:".
When reading the '+' the parser determines that it is not end of CDATA
and will write ']', ']' and '+' to the buffer. Now it could happen
that when reading the '+' the parser is at the end of the read buffer
(nextIn == lastIn) and will flush the buffer setting count = 0 and
nextIn = 1. Writing the reamining characters will now overwrite nextIn,
that is the ':' with second ']'. So write has to check if count is
still less than nextIn.
In MinML$MinMLBuffer an implementation for write would be, assuming
that nextIn will never be 0.
public void write(final int c) throws IOException {
// flush if there is not enough space for the character
if (written && count == nextIn)
_flush();
written = true;
chars[count++] = (char)c;
}
public void write(final char[] cbuf, final int off, final int len) throws
IOException {
// flush if there is not enough space for the array
if (written && (count + len) >= nextIn)
_flush();
// Write single characters if there is still not enough space
if (count + len >= nextIn) {
for (int i = 0; i < len; i++)
write(cbuf[off+i]);
return;
}
written = true;
System.arraycopy(cbuf, off, chars, count, len);
count += len;
}
Sorry I can't give you a diff context since I changed more than that in MinML
(I had to determine the enconding of the XML file).
Regards
Christoph Theis
