Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
If the user's locale is broken, it's perfectly ok in my book for Wine to be broken too. Picking a random environment variable and saying "We will use this one and not that one" is utter nonsense. Just so things are clear, picking LC_ALL and LANG for the system locale, but not LC_CTYPE is precisely that - picking random variables as representing of functionality typically provided by other variables.
LC_ALL and LANG are not random variables, that's what glibc uses for internal locale setup.
Ignoring LC_CTYPE is as random as ignoring any other one. For the 100th time, we are not ignoring LC_ALL and LANG. We are simply ALSO looking at LC_CTYPE.
The flip side of your argument regarding broken locales now being broken on Wine as well is that, if this patch is reverted, perfectly valid locales (such as mine - LANG=en_US, LC_CTYPE=he_IL) are broken.
Your locale is broken, and I already explained why. You are lucky that en_US has no conflicting with he_IL characters in the upper ASCII table. Just replace en_US by fr_FR, de_DE or ru_RU. Why are you ignoring this fact?
Because it's irrelevant whether there are broken locales that have LC_CTYPE different than LANG. The right question is whether there are NON broken locales of that type. Luck has nothing to do with it. If the setup I'm using was not working, I wouldn't be using it. Another interesting question is whether there are non-broken Unix locales that result in a broken Wine locale as a result of this patch. The answers, as you correctly state in this very question, is YES and NO respectively, meaning there appears to be no base in reality for your categorical claim that ANY setup with LC_CTYPE is broken.
In other words - my system is running such a locale. Why is it that you wish to break my setup? Especially since it doesn't affect your setup at all!
Now which do you prefer? Broken setups not being "fixed", or valid setups being broken?
I prefer not introduce potentially confusing things. I'm still waiting for the test cases and explanations what exactly APIs are affected by system/user locale in Windows and what users should expect when they have different system and user locale. Until you answer that questions I don't see how you would argue that your patch is correct and does exactly the same thing as supposed to happened under Windows.
We have a property called "LC_CTYPE" on Unix. We have a property called "System locale" on Windows. They are both documented and observed to do exactly the same. Mapping one to the other seems the right thing to do.
There is no need to create an elaborate system of test cases just so I can prove something which appears to be right is really right. If you are so certain it's wrong, why don't you do one of two things: 1. Show us that LC_CTYPE and system locale are NOT the same thing. 2. Show us what system APIs functionality is broken by this patch.
Please bear in mind that I can't think of a single case of 2 above for which the answer would be "System locale should not be affected by LC_CTYPE". I am much more likely to think "the specific API you found to break is the curl pit". I am, however, open to be shown wrong on this.
The most curious thing for me is that this patch does not even affect your setup. If you didn't touch LC_CTYPE (as you claim no one should), why should you care about this patch? It will still take system locale from LANG if LC_CTYPE is not defined.
In other words, this patch fixes Wine on my system without breaking it on yours. Any system on which it does break is a system you categorically call broken to begin with (LC_CTYPE points elsewhere from LANG). Why do you object so much?
Shachar