That should never fail with e.g. locale us.utf8. The collate should be equal to the Ansi collate. Still it fails. That's the point.... For 0..127 us_US.UTF8 equals Ansi
It did not fail. It did what it is supposed to do, but not what you expect. For instance, small letters are before capital letters, contrary to ASCII.
It is not Ascii, but full Ansi. the first 256 characters in Unicode (and ucs2) are even specified as win CP1252 and nix ISO-8859-1 (these are similar but not quite the same) .
That should *never* affect collate order. And is the official specification.
It is ASCII at least for POSIX locale. Search for ASCII
here.
Where did you get that from?
Don't remember. I'll see if I can find it. But it is easy to check your locale, either do the comparison using your system API, like CompareString on Windows, or better get the weights used in the final binary comparison.
You can get these weights on Windows using LCMapString. Notice that the figures are implementation dependent. Windows uses the following format:
[all Unicode sort weights] 0x01 [all Diacritic weights] 0x01 [all Case weights] 0x01 [all Special weights] 0x00
Collate order defaults to natural sort order for at least these first 128 characters and defaults also to natural order of cp1252/iso-8859-1 for the next 128.. Nothing reversed.
You are talking about POSIX locale. Any locale could change that order. According to the results on your system, and EganSolo's, your locales reversed the order, hence you both have this normal confusion.
Again, Windows CompareString, and wcstring's strcoll both are locale dependent. The locales on your systems are reversing the order of capital/small letters. Test my statement using CompareString/strcoll.