On Fri, 24 Feb 2006 10:48:47 -0800 Lei Zhang leiz@ucla.edu wrote:
On Friday 24 February 2006 04:39 am, Phil Krylov wrote:
On Fri, 24 Feb 2006 12:24:45 +0100
Alexandre Julliard julliard@winehq.org wrote:
Phil Krylov phil@newstar.rinet.ru writes:
On Tue, 21 Feb 2006 14:08:38 -0800
Lei Zhang leiz@ucla.edu 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.