<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 12/03/18 10:36, Huw Davies wrote:<br>
</p>
<blockquote type="cite"
cite="mid:20180312153602.GF26970@merlot.physics.ox.ac.uk">
<pre wrap="">On Mon, Mar 12, 2018 at 10:31:31AM -0500, Sergio Gómez Del Real wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/03/18 10:13, Huw Davies wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, Mar 12, 2018 at 09:39:16AM -0500, Sergio Gómez Del Real wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Grrr, right. This is why you'd do the normailization before calling
CompareStringEx().
Huw.
</pre>
</blockquote>
<br>
I'm not really sure what assumptions I can make to avoid an o(n.m),
since both of the strings can be presented with characters in any
(pre)composed form... I don't know if the trouble trying to find a
way to upper-bound the search with a length (3x? 5x?) would be worth
considering that it seems to be the normal case that we don't get
too long strings to compare, and relatively little use of the
function itself. Would brute-force o(n.m) be <i>too</i> bad?<br>
</body>
</html>