http://bugs.winehq.org/show_bug.cgi?id=10767
Summary: lstrcmp and others do not compare punctuation characters correctly Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-kernel AssignedTo: wine-bugs@winehq.org ReportedBy: lich@math.spbu.ru
just example:
ret = lstrcmpi("# (Search for Disassembly Pattern)", ".RELOAD (Reload Symbols)");
wine returns '1' here, but must '-1' since ord('#')=23h < 2Eh=ord('.'). Windows handles this case correctly. GLIBC strcasecmp works correctly too.
This bug heavily affects winhelp index lookup in WIN32.HLP borland help file, which has lots of #.&*()[]
P.S. It is not a locale problem, so this bug is not a duplicate of bug #9583
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2007-12-13 22:11:20 --- Wine uses unicode.org collation table (www.unicode.org/reports/tr10/allkeys.txt) which has the following data:
0023 ; [*02A9.0020.0002.0023] # NUMBER SIGN 002E ; [*0255.0020.0002.002E] # FULL STOP
http://bugs.winehq.org/show_bug.cgi?id=10767
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
--- Comment #2 from Austin English austinenglish@gmail.com 2008-06-04 14:45:37 --- Is this still an issue in 1.0-rc3?
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #3 from Kirill K. Smirnov lich@math.spbu.ru 2008-06-04 16:08:36 ---
Is this still an issue in 1.0-rc3?
Yes, it is.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #4 from Austin English austinenglish@gmail.com 2008-12-02 06:58:43 --- Please retest in 1.1.9.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #5 from Kirill K. Smirnov lich@math.spbu.ru 2008-12-02 08:08:14 ---
Please retest in 1.1.9.
Nothing changed, it is still a bug.
http://bugs.winehq.org/show_bug.cgi?id=10767
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #6 from Austin English austinenglish@gmail.com 2009-01-18 03:47:09 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=10767
Kirill K. Smirnov lich@math.spbu.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.10.
--- Comment #7 from Kirill K. Smirnov lich@math.spbu.ru 2009-01-18 09:32:02 --- Still present
http://bugs.winehq.org/show_bug.cgi?id=10767
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #8 from Austin English austinenglish@gmail.com 2009-07-21 14:47:37 --- Looks like Nikolay added a testcase a while back: http://source.winehq.org/git/wine.git/?a=commitdiff;h=4e12b8efc829cdac306c59...
which is still todo_wine. Do we really need to keep this bug open..?
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com 2009-07-21 15:30:09 --- (In reply to comment #8)
Looks like Nikolay added a testcase a while back: http://source.winehq.org/git/wine.git/?a=commitdiff;h=4e12b8efc829cdac306c59...
which is still todo_wine. Do we really need to keep this bug open..?
Yes, cause it isn't fixed yet.
http://bugs.winehq.org/show_bug.cgi?id=10767
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com 2009-10-11 15:16:57 --- Confirming, committed test is still todo_wine.
http://bugs.winehq.org/show_bug.cgi?id=10767
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl 2009-11-13 15:36:36 --- Considering well-documented et_EE locale failures, is it even a good idea to try for a language-independent collation ?
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #12 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-16 12:35:39 --- (In reply to comment #11)
Considering well-documented et_EE locale failures, is it even a good idea to try for a language-independent collation ?
Unicode has been supposedly invented exactly for locale independent things.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #13 from Rafał Mużyło galtgendo@o2.pl 2009-11-16 13:16:21 --- (In reply to comment #12)
Unicode has been supposedly invented exactly for locale independent things.
It was invented to *encode* all already established charsets plus have a bit of spare space. However, that's not the same as language independent *collation*: et_EE locale is a prime example that it doesn't work even in ASCII range.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-16 13:25:42 --- (In reply to comment #13)
However, that's not the same as language independent *collation*: et_EE locale is a prime example that it doesn't work even in ASCII range.
Unicode introduces completely locale/language independent collation. That's the whole point of unicode.
The source of this bug is in the incompatibility of unicode.org and Microsoft collation tables, there is no need to add more confusion or speculation than there is already.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #15 from Rafał Mużyło galtgendo@o2.pl 2009-11-16 15:15:15 --- You're completely missing the point - if even ASCII strings can't be sorted language independently, then that "Unicode collation table" implements a sorting scheme that is more or less broken for any language.
That table is just a template for languages to have some sorting scheme for chars that are *outside* that language.
I think even the docs on that site say so, just in a bit vague terms.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #16 from Rafał Mużyło galtgendo@o2.pl 2009-11-16 15:21:19 --- The main point is that even mdsn says, that lstrcmpi is locale dependent.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #17 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-17 01:51:56 --- (In reply to comment #15)
You're completely missing the point - if even ASCII strings can't be sorted language independently, then that "Unicode collation table" implements a sorting scheme that is more or less broken for any language. That table is just a template for languages to have some sorting scheme for chars that are *outside* that language.
Sounds like you don't understand what is unicode and how charsets map into it.
The main point is that even mdsn says, that lstrcmpi is locale dependent.
There is no such an API as "lstrcmpi" in win32. Surprise?
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #18 from Rafał Mużyło galtgendo@o2.pl 2009-11-17 02:43:07 --- http://msdn.microsoft.com/en-us/library/ms647489%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms647488%28VS.85%29.aspx
Among other: The language (user locale) selected by the user at setup time, or through Control Panel, determines which string is greater (or whether the strings are the same). If no language (user locale) is selected, the system performs the comparison by using default values.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-17 02:53:35 --- Neither lstrcmpi no lstrcmp are the real APIs, you need to differentiate between A and W variants. W version doesn't care about locale, while A does.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #20 from Rafał Mużyło galtgendo@o2.pl 2009-11-17 03:28:01 --- Well, as far as I understand the current code: when lstrcmp(i) is called, locale matters only till MultiByteToWideChar is called, then it goes to CompareStringW which eventually does wine_compare_string - this function is that language independent comparison, that I'm complaining about.
On a related note: this blog: http://blogs.msdn.com/michkap/default.aspx has a few interesting posts about similar problems.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #21 from Rafał Mużyło galtgendo@o2.pl 2009-11-17 03:34:41 --- I.e. this post http://blogs.msdn.com/michkap/archive/2009/09/14/9894607.aspx quotes the part of Unicode docs I was trying to refer to.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-17 05:57:51 --- Once again:
The source of this bug is in the incompatibility of unicode.org and Microsoft collation tables, there is no need to add more confusion or speculation than there is already.
All the talk about locales is meaningless in the unicode context.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl 2009-11-17 09:21:40 --- (In reply to comment #22)
Once again:
The source of this bug is in the incompatibility of unicode.org and Microsoft collation tables, there is no need to add more confusion or speculation than there is already.
All the talk about locales is meaningless in the unicode context.
That's only a part of the problem. The other is wine design.
That quote from the standard docs says: The Default Unicode Collation Element Table does not aim to provide precisely correct ordering for each language and script; tailoring is required for correct language handling in almost all cases.
So, sorting, that uses it, may give you invalid results for a particular language. It may be useful for pure collation, but not for plain sorting.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2009-11-17 09:41:09 --- (In reply to comment #23)
That's only a part of the problem. The other is wine design.
That quote from the standard docs says: The Default Unicode Collation Element Table does not aim to provide precisely correct ordering for each language and script; tailoring is required for correct language handling in almost all cases.
So, sorting, that uses it, may give you invalid results for a particular language. It may be useful for pure collation, but not for plain sorting.
Again, this has nothing to do with this bug. Please stop adding confusion. If you have an app that fails because of incorrect locale-dependent sorting, please file another bug for that problem.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #25 from Rafał Mużyło galtgendo@o2.pl 2009-11-17 15:24:28 --- (In reply to comment #24)
Again, this has nothing to do with this bug. Please stop adding confusion. If you have an app that fails because of incorrect locale-dependent sorting, please file another bug for that problem.
But the point is - it does. wine_compare_string uses that collation table for string *comparison* - that quote from Unicode docs says that's wrong. While result 'equal' does have a meaning, 'not equal' does not. It tells nothing about how those strings should be sorted, as the actual result is *always* language dependent.
This whole problem here comes from using collation table as something that provides data for plain string sorting, but that quote clearly says it should *not* be used that way.
While I didn't do any real tests, I think that that et_EE locale would give you a good counter example. (though I don't know, if Microsoft actually created Estonian localization, given significantly small size of the market)
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #26 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-17 23:50:03 --- Please stop posting useless comments to this bug.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #27 from Rafał Mużyło galtgendo@o2.pl 2009-11-18 04:30:19 --- So, I'll put it in simple terms: IMHO, this starts looking just like winealsa case did: "snd_pcm_delay may reach zero, but doesn't ever have to". Here, it's "DUCET may give you good results for string *sorting*, but by no means it has to".
IOW, wrong assumption.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #28 from Alexandre Julliard julliard@winehq.org 2009-11-18 04:48:59 --- Once again, please drop this. You are not adding any useful information to this bug.
http://bugs.winehq.org/show_bug.cgi?id=10767
Sergey Kvachonok ravenexp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ravenexp@gmail.com
--- Comment #29 from Sergey Kvachonok ravenexp@gmail.com 2010-07-31 14:39:20 --- Still present in 1.2.
lstrcmpiA(".", "_") == 1 in wine, while it's -1 in windows and < 0 for strcasecmp with any glibc locale I tried.
Seriously, ASCII '.' = 0x2E, ASCII '_' = 0x5F. Is it that hard to figure out? As it is it's breaking any case-insensitive indexes relying on case insensitive sorting of ASCII strings. It's not just presentation problem, applications can't read their data because binary/tree searches fail on wine.
Is there a way to make it work at least for ASCII range, using LC_COLLATE or LC_CTYPE or whatever? I believe a lot less if any windows code depends on obscure Unicode collation rules, so this should can come after fixing this bug.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #30 from Rafał Mużyło galtgendo@o2.pl 2010-07-31 18:26:20 --- I still hold the opinion, that to do it without dropping the idea of "comparison by collation" would require the use of something like ICU.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #31 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-01 01:44:42 --- (In reply to comment #29)
Seriously, ASCII '.' = 0x2E, ASCII '_' = 0x5F. Is it that hard to figure out?
Feel free to file a bug at unicode.org
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #32 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-01 01:53:28 --- (In reply to comment #30)
I still hold the opinion, that to do it without dropping the idea of "comparison by collation" would require the use of something like ICU.
Wine already has its own collation implementation. You are going in circles, please stop adding useless comments to this bug.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #33 from Sergey Kvachonok ravenexp@gmail.com 2010-08-01 03:57:20 --- (In reply to comment #31)
(In reply to comment #29)
Seriously, ASCII '.' = 0x2E, ASCII '_' = 0x5F. Is it that hard to figure out?
Feel free to file a bug at unicode.org
Please stop blaming unicode people for this. There is more than one way to sort character strings, so the whole point of theoretical correctness of the current approach is useless.
For example:
In the POSIX locale, strcasecmp() and strncasecmp() shall behave as if the strings had been converted to lowercase and then a byte comparison performed. The results are unspecified in other locales.
Sane, stable and sufficiently specified.
Unfortunately, windows takes some other (third) approach to this, as I found here: http://www.mail-archive.com/wine-devel@winehq.org/msg56188.html
Furthermore, it is clearly stated that unicode collation rules are language and locale dependent: http://cldr.unicode.org/index/cldr-spec/collation-guidelines
I believe wine as a windows _emulator_ should have exactly the same behavior as winapi, right or not. Given that locale-specific customizations are unavoidable, windows-style collation tables must be at least an option, if not default.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #34 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-01 05:13:10 --- (In reply to comment #33)
Seriously, ASCII '.' = 0x2E, ASCII '_' = 0x5F. Is it that hard to figure out?
Feel free to file a bug at unicode.org
Please stop blaming unicode people for this. There is more than one way to sort character strings, so the whole point of theoretical correctness of the current approach is useless.
Please re-read all the comments above, starting from the comment #1.
For example:
In the POSIX locale, strcasecmp() and strncasecmp() shall behave as if the strings had been converted to lowercase and then a byte comparison performed. The results are unspecified in other locales.
Sane, stable and sufficiently specified.
Unfortunately, windows takes some other (third) approach to this, as I found here: http://www.mail-archive.com/wine-devel@winehq.org/msg56188.html
Furthermore, it is clearly stated that unicode collation rules are language and locale dependent: http://cldr.unicode.org/index/cldr-spec/collation-guidelines
See the comment #24.
I believe wine as a windows _emulator_ should have exactly the same behavior as winapi, right or not. Given that locale-specific customizations are unavoidable, windows-style collation tables must be at least an option, if not default.
Wine is not an emulator, believe you to it or not doesn't matter.
If you think that Wine should copy unicode collation tables from Windows and be done with it at least think of a legal subsequences of this approach.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #35 from Sergey Kvachonok ravenexp@gmail.com 2010-08-01 06:45:57 --- (In reply to comment #34)
If you think that Wine should copy unicode collation tables from Windows and be done with it at least think of a legal subsequences of this approach.
I'm not a lawyer, so I don't see much difference between reimplementing proprietary api with 1000+ functions and reimplementing particular sorting order. Wine implements windows-specific character encodings after all.
Please clarify this to me: If windows-specific tables were somehow obtained (e.g. indirectly via calling specific API functions, sorting strings, etc.), will they be incorporated in upstream wine? Or will this be rejected as possible legal hazard? I'd like to see some comments before I start wasting time on this. Any directions would be welcome.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #36 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-01 07:51:42 --- (In reply to comment #35)
If you think that Wine should copy unicode collation tables from Windows and be done with it at least think of a legal subsequences of this approach.
I'm not a lawyer, so I don't see much difference between reimplementing proprietary api with 1000+ functions and reimplementing particular sorting order.
Don't you see a difference between reimplementing something from scratch and copying from other place, especially since that place is Windows?
Wine implements windows-specific character encodings after all.
Wine implements it using the data tables provided by unicode.org
Please clarify this to me: If windows-specific tables were somehow obtained (e.g. indirectly via calling specific API functions, sorting strings, etc.), will they be incorporated in upstream wine? Or will this be rejected as possible legal hazard? I'd like to see some comments before I start wasting time on this. Any directions would be welcome.
Copying Windows data into Wine is not acceptable.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #37 from Rafał Mużyło galtgendo@o2.pl 2010-08-01 12:02:52 --- You know what ? You're right.
My comments don't carry a solution, they just reiterate the obvious - DUCET itself states it's NOT meant to be used the way, wine uses it.
Of course, as long as some people believe such idea is the best thing since sliced bread, this bug will stay a question of FAITH, instead of facts.
Cause, you know, projects like sqlite (so rather lightweight), use ICU just cause it's fun to do so.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #38 from Alexandre Julliard julliard@winehq.org 2010-08-01 12:21:12 --- You have been asked repeatedly to stop adding noise to this bug. If you think you have a solution send a patch, otherwise just leave this bug alone. You are not helping.
http://bugs.winehq.org/show_bug.cgi?id=10767
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=10767
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ntrrgc@gmail.com
--- Comment #39 from Alexandre Julliard julliard@winehq.org 2012-07-10 22:33:45 CDT --- *** Bug 31191 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #40 from Rafał Mużyło galtgendo@o2.pl 2012-07-16 12:10:40 CDT --- (In reply to comment #39)
*** Bug 31191 has been marked as a duplicate of this bug. ***
To the hopeful one, whose bug has been marked as a duplicate of this one, that has just sent a patch: abandon all hope.
http://blogs.msdn.com/b/michkap/archive/2005/02/05/367666.aspx
This is why I've tried ICU in the past, but just couldn't make it.
So, your patch may make things better in some of the cases, but as long as current approach is upheld, it won't be a real fix.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #41 from Rafał Mużyło galtgendo@o2.pl 2012-07-21 15:12:33 CDT --- ...and in regard of http://source.winehq.org/patches/data/88456 I never looked closer on those tests, but now that you've pointed it out, I suspect
/* \xB9 character lies between a and b */ ret = CompareStringA(lcid, 0, "a", 1, "\xB9", 1); todo_wine ok(ret == CSTR_LESS_THAN, "'\xB9' character should be greater than 'a'\n"); ret = CompareStringA(lcid, 0, "\xB9", 1, "b", 1); ok(ret == CSTR_LESS_THAN, "'\xB9' character should be smaller than 'b'\n");
is kind of broken right now, just in a different way.
In the light of the previously mentioned article, it's missing a section alike to:
ret = CompareStringA(lcid, NORM_IGNORENONSPACE, "a", 1, "\xB9", 1); todo_wine ok(ret == CSTR_LESS_THAN, "'\xB9' character should be greater than 'a'\n");
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #42 from Juan Luis ntrrgc@gmail.com 2012-07-22 07:49:17 CDT --- (In reply to comment #41)
In the light of the previously mentioned article, it's missing a section alike to:
ret = CompareStringA(lcid, NORM_IGNORENONSPACE, "a", 1, "\xB9", 1); todo_wine ok(ret == CSTR_LESS_THAN, "\'\\xB9\' character should be greaterthan 'a'\n");
Sure. Work has been done in working with all ascii strings. Unicode ones still can fail in many ways, but finally fixing them would need more time... and some new collation tables.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #43 from Rafał Mużyło galtgendo@o2.pl 2012-07-22 08:06:43 CDT --- (In reply to comment #42)
(In reply to comment #41)
In the light of the previously mentioned article, it's missing a section alike to:
ret = CompareStringA(lcid, NORM_IGNORENONSPACE, "a", 1, "\xB9", 1); todo_wine ok(ret == CSTR_LESS_THAN, "\'\\xB9\' character should be greaterthan 'a'\n");
Sure. Work has been done in working with all ascii strings. Unicode ones still can fail in many ways, but finally fixing them would need more time... and some new collation tables.
The problem here is that the same test in LOCALE_INVARIANT case should return CSTR_EQUAL (as noted in the article). That's why my failed idea was ICU. During last discussion of this topic, mono collation tables came up, but I can't deal with its syntax.
http://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #44 from Juan Luis ntrrgc@gmail.com 2012-07-22 12:30:11 CDT --- (In reply to comment #43)
(In reply to comment #42)
(In reply to comment #41)
In the light of the previously mentioned article, it's missing a section alike to:
ret = CompareStringA(lcid, NORM_IGNORENONSPACE, "a", 1, "\xB9", 1); todo_wine ok(ret == CSTR_LESS_THAN, "\'\\xB9\' character should be greaterthan 'a'\n");
Sure. Work has been done in working with all ascii strings. Unicode ones still can fail in many ways, but finally fixing them would need more time... and some new collation tables.
The problem here is that the same test in LOCALE_INVARIANT case should return CSTR_EQUAL (as noted in the article). That's why my failed idea was ICU. During last discussion of this topic, mono collation tables came up, but I can't deal with its syntax.
What about this? http://msdn.microsoft.com/en-us/library/cc248954%28v=prot.10%29.aspx
https://bugs.winehq.org/show_bug.cgi?id=10767
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Abandoned?, source
--- Comment #45 from Ken Sharp imwellcushtymelike@gmail.com --- Is this still an issue in Wine 1.7.45 or later?
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #46 from Kirill K. Smirnov lich@math.spbu.ru --- (In reply to Ken Sharp from comment #45)
Is this still an issue in Wine 1.7.45 or later?
Yes, wine still returns 1 instead of -1.
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #47 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Ken Sharp from comment #45)
Is this still an issue in Wine 1.7.45 or later?
How could it not be ?
As long as the whole method isn't rewriten to return locale specific results, this will stay broken.
https://bugs.winehq.org/show_bug.cgi?id=10767
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|Abandoned? |
https://bugs.winehq.org/show_bug.cgi?id=10767
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/libs-Unicode_C | |ollation
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #48 from Rafał Mużyło galtgendo@o2.pl --- Wrt. wine-staging patch: comment 47 holds.
https://bugs.winehq.org/show_bug.cgi?id=10767
Kevin Haroldsen kupiakos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kupiakos@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=10767
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=10767
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #49 from Nikolay Sivov bunglehead@gmail.com --- This doesn't count as a valid fix.
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #50 from Austin English austinenglish@gmail.com --- (In reply to Nikolay Sivov from comment #49)
This doesn't count as a valid fix.
It doesn't matter if it's a valid fix, the keyword is to indicate that there is a patch available for the issue. It's likely expected that most patches on bugzilla aren't valid fixes, otherwise they'd already be committed ;)
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #51 from Kevin Haroldsen kupiakos@gmail.com --- (In reply to Nikolay Sivov from comment #49)
This doesn't count as a valid fix.
Even if the patch doesn't fully solve the problem with StringCompare and locales, doesn't it solve this specific bug?
https://bugs.winehq.org/show_bug.cgi?id=10767
Mokou mokouthrowaway@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mokouthrowaway@gmail.com
--- Comment #52 from Mokou mokouthrowaway@gmail.com --- *** Bug 40407 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=10767
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #53 from winetest@luukku.com --- bug 36690 is analyzed to have similar or same issue than this bug. It just needs to somekind of confirm/testing.
https://bugs.winehq.org/show_bug.cgi?id=10767
zaplo00@mailfence.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zaplo00@mailfence.com
https://bugs.winehq.org/show_bug.cgi?id=10767
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/libs-Unicode_C |er/patches/libs-Unicode_Col |ollation |lation CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #54 from Rafał Mużyło galtgendo@o2.pl --- Sorry for the noise.
Updating the link from comment 40. The original blog is dead, just as its author (or so it seem by google).
An archive link is http://archives.miloush.net/michkap/archive/2005/02/05/367666.html.
https://bugs.winehq.org/show_bug.cgi?id=10767
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #55 from Fabian Maurer dark.shadow4@web.de --- I'm currently working on a proper solution for this. Just need to get it upstreamed, which will probably take some time still.
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #56 from Rafał Mużyło galtgendo@o2.pl --- So, given juliard's recent activities in kernelbase (that - AFAICT - invalidated the patch that got sent to the list (or at least made highly incompatible): https://www.winehq.org/pipermail/wine-devel/2020-February/159934.html), is it reasonable to expect this problem will also be addressed in a no-too-far future ?
https://bugs.winehq.org/show_bug.cgi?id=10767
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nailer592899230@halestrom.n | |et
--- Comment #57 from Fabian Maurer dark.shadow4@web.de --- *** Bug 49778 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #58 from Fabian Maurer dark.shadow4@web.de --- Sorry for the late response, but I can tell you that Alexandre Julliard did a bunch of very welcome changes that make it a lot easier for my patchset. I've already rewrote it for those changes and it mostly works already, but I need to still do major refactoring, so it might still take a while. Sorry for the wait.
https://bugs.winehq.org/show_bug.cgi?id=10767
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |NEW
--- Comment #59 from Gijs Vermeulen gijsvrm@gmail.com --- The staging patchset has been disabled for a while, removing STAGED status.
https://bugs.winehq.org/show_bug.cgi?id=10767
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |z.figura12@gmail.com
--- Comment #60 from Zebediah Figura z.figura12@gmail.com --- The patch has been replaced.
https://bugs.winehq.org/show_bug.cgi?id=10767
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hibi.sasahara@gmail.com
--- Comment #61 from Fabian Maurer dark.shadow4@web.de --- *** Bug 35009 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #62 from Fabian Maurer dark.shadow4@web.de --- Since there hasn't been complaints about breakages I will work on upstreaming this after the code freeze.
https://bugs.winehq.org/show_bug.cgi?id=10767
temp82@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82@luukku.com
--- Comment #63 from temp82@luukku.com --- (In reply to Fabian Maurer from comment #62)
Since there hasn't been complaints about breakages I will work on upstreaming this after the code freeze.
just a reminder. :)
https://bugs.winehq.org/show_bug.cgi?id=10767
--- Comment #64 from Sagawa sagawa.aki+winebugs@gmail.com --- This issue seems to be fixed by d8c973ad95ba5e8a9a51df0dd9be587950179ec3. With the above commit, lstrcmpi("#",".") returns '-1'.
https://bugs.winehq.org/show_bug.cgi?id=10767
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |d8c973ad95ba5e8a9a51df0dd9b | |e587950179ec3
--- Comment #65 from Alexandre Julliard julliard@winehq.org --- Fixed now.
https://bugs.winehq.org/show_bug.cgi?id=10767
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #66 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.10.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla