[PATCH v2] kernel32: Implement FindNLSStringEx. Tests included.

[Huw Davies]

On Mon, Mar 12, 2018 at 10:31:31AM -0500, Sergio Gómez Del Real wrote:
> On 12/03/18 10:13, Huw Davies wrote:
> 
> >On Mon, Mar 12, 2018 at 09:39:16AM -0500, Sergio Gómez Del Real wrote:
> >>On 12/03/18 06:03, Nikolay Sivov wrote:
> >>      On 3/12/2018 12:25 PM, Huw Davies wrote:
> >>                +                           LPARAM sort_handle)
> >>                +{
> >>                +
> >>                +    DWORD mask = flags;
> >>                +
> >>                +    TRACE("%s %x %s %d %s %d %p %p %p %ld\n",
> >>                wine_dbgstr_w(localename), flags,
> >>                +          wine_dbgstr_w(src), src_size,
> >>                wine_dbgstr_w(value), value_size, found,
> >>                +          version_info, reserved, sort_handle);
> >>                +    FIXME("strings should be normalized once
> >>                NormalizeString() is implemented\n");
> >>           I don't think we want the noise that this FIXME would
> >>           generate.  Just add a comment.
> >>      Actually it might be possible that CompareString() handles decomposed
> >>      case on its own, I haven't tested that.
> >>
> >>Yeah, you are right Nikolai; I just tested on Windows and it seems that
> >>CompareString() shares the same comparison semantics with FindNLSStringEx(). On
> >>Wine it fails, however, so I guess I'd code FindNLSStringEx() assuming a
> >>working CompareString(), and then see what is missing there.
> >>I actually had it like this in my first patch, relying on CompareString
> >>(assuming the shared semantics). I wanted to normalize first in this v2 patch
> >>so that the substring search would be worst case o(n) instead of o(n.m).
> >>However, reading the Unicode standard, it seems that I can make some
> >>assumptions about the maximum expansion factor in decomposition (when assuming
> >>canonical decomposition).
> >If CompareStringEx handles the normailization, then you'd call it in
> >pretty much the same way as you do in the current patch (though you'd
> >loop right through to the end, not stopping value_size from the end).
> >The tricky bit would be getting the 'found' length.  For that you'd
> >probably use an internal version of CompareStringEx that returned
> >this info.
> >
> >For now, I'd stick with the fixme comment.
> >
> >Huw.
> Hi, Huw,
> Maybe I'm not following well, but in the current patch I'm always calling
> CompareStringEx() with the same string length for both strings (value_size).
> Being this the case, I'm not sure if CompareStringEx() would succeed when it
> needs to, even if it did normalization.

Grrr, right.   This is why you'd do the normailization before calling
CompareStringEx().

Huw.