On Monday 23 July 2001 22:16, Glenn Marcy wrote:
> Keep in mind that when the toString() method is called it is reading the
> UTF-8 bytestream for the SECOND time. The UTF8Reader has already parsed
> the bytestream to find the offset and length of each "string" that the
> StringPool provides a handle for. Therefore, the endOffset will never
> be in the middle of a multibyte character.
[snip]
> tests was false, it would have been one of the other byte fetches that
> got the ArrayIndexOutOfBoundsException.
That is correct. Moreover, if I was encountering this problem, it would
happen every time, on any box. Which is not the case. However, I still
replied since I thought this was a bug (though unrelated).
Howeve:
> The only reason for the && offset < endOffset part of the test is to
> handle the case when a string ends on the last byte of a chunk. In this
> case the fNextChunk pointer is null and we do not want to dereference
> the null pointer to move to the next chunk when there is no data to
> fetch from that chunk. The code could be:
>
> if (index == CHUNK_SIZE) {
> if (offset < endOffset) {
> dataChunk = dataChunk.fNextChunk;
> data = dataChunk.fData;
> }
> index = 0;
> }
Well, I think it should be rewritten like this, because it make an obscure
invariant (that only a very few people can be aware of), explicit in the
code. It makes the code a lot less context dependant. In fact, maybe even
better, it can be:
if (index == CHUNK_SIZE) {
dataChunk = dataChunk.fNextChunk;
data = dataChunk == null ? null : dataChunk.fData;
index = 0;
}
This way, if we do have a bug, we'll deference data, and we'll get a
NullPointerException.
--
Dimi.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
