riched20: Implements FR_MATCHCASE for EM_FINDTEXT

[Phil Krylov]

On Fri, 24 Feb 2006 10:48:47 -0800
Lei Zhang <leiz at 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 at winehq.org> wrote:
> > > Phil Krylov <phil at newstar.rinet.ru> writes:
> > > > On Tue, 21 Feb 2006 14:08:38 -0800
> > > >
> > > > Lei Zhang <leiz at 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.