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

[Sergio Gómez Del Real]

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).

/"There is also a Unicode Consortium stability policy that canonical 
mappings are always limited in all versions of Unicode, so that no 
string when decomposed with NFC expands to more than 3× in length 
(measured in code units). This is true whether the text is in UTF-8, 
UTF-16, or UTF-32. This guarantee also allows for certain optimizations 
in processing, especially in determining buffer sizes"

/Although it seems that the worst case possible is a 18x expansion 
factor when using normalization form NFKC, it looks like these functions 
only test for canonical equivalence, so I guess it would be ok to assume 
a worst case of 3x for the length to keep things o(n).

Does this sound right to you?
//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180312/e5fc81bd/attachment-0001.html>