nsScanner::RewindToMark() doesn't check if mSlidingBuffer is initialized. This causes bug 107945 and bug 107994.

r=harishd

May be we need a similar check in nsScanner::UngetReadable().

If we do so, we can fix another bug in nsScanner::UngetReadable() with mCountRemaining not being updated (should have filed a separate bug for that, but I saw no actual problem with it in the trunk). BTW, why does nsScanner::UngetReadable() return a PR_BOOL? I assume PR_TRUE means success and PR_FALSE failure.

Found another function where mCurrentPosition and mEndPosition might be undefined: CopyUnusedData().

Should we try to get this reviewed & checked in? We could then also remove at least one hack (nsParser.cpp line 2435-2439).

It seems like most of the problems that this bug would have fixed are fixed by bug 182067. With that fix in, I think anybody who tries to do anything usefull with a scanner with no data will get eof (i.e., reading the next char). I can create an updated patch with the rest of the functions null-checked, but I can't imagine why or how anybody would want to UngetReadable (or RewindToMark, etc.) on an empty buffer (where would they unget from? They would have started at eof). Also note: CopyUnusedData would no longer need an explicit null-check, except to avoid the function call, because for an empty scanner we guarentee mCurPosition==mEndPosition.

Well.. we don't need to do anything _useful_ on those calls. But unless the API explicitly prohibits them, we shouldn't crash....

This patch adds null-checks to all functions accessing mSlidingBuffer. The only difference of any note between it and the current one is that I haven't bothered updating the javadoc comments, as they're all so out of date anyway.

Comment on attachment 149796 [details] [diff] [review] updated patch bz, could you give this review and check it in please?

Comment on attachment 149796 [details] [diff] [review] updated patch r+sr=bzbarsky

Checked in.