On Fri, 24 Feb 2006 10:48:47 -0800 Lei Zhang <[EMAIL PROTECTED]> wrote:
> On Friday 24 February 2006 04:39 am, Phil Krylov wrote: > > On Fri, 24 Feb 2006 12:24:45 +0100 > > > > Alexandre Julliard <[EMAIL PROTECTED]> wrote: > > > Phil Krylov <[EMAIL PROTECTED]> writes: > > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > > > > > > > Lei Zhang <[EMAIL PROTECTED]> wrote: > > > >> Hi Phil, > > > >> > > > >> Ya, it's a typo. Thanks for catching it. > > > > > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > > > > > I accepted the patch because I don't see how pCurItem could be NULL > > > in that loop (or rather, it could be NULL, but in that case we'll > > > crash before coming back to the loop test). Am I missing something? > > > > Yes, you're right. It can't be NULL because of an earlier test: > > > > para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen > > >= nMin > > > > But this is very inevident. > > > > -- Ph. > > Hi Phil, Alex > > Yes, it can become NULL, here's how: > > Inside while (ME_CharCompare(pCurItem->.... ) > the last if() block assigns a new value to pCurItem, which may be NULL. It may but it won't... ME_FindItemBack(pCurItem) will return NULL only if pCurItem is the first text run in the document. But the if() condition (nCurEnd - nMatched == 0) is TRUE only if the search string is longer than nCurEnd. This does not happen for the first document run because of the condition of the exterior loop which checks if we have enough characters for comparison. --Ph.
