It's a requirement for any comparison sort to work that the underlying order operator is transitive and antisymmetric.
In .NET, that's not true for some strings:
static void CompareBug()
{
string x = "u002Du30A2"; // or just "-ア" if charset allows
string y = "u3042"; // or just "あ" if charset allows
Console.WriteLine(x.CompareTo(y)); // positive one
Console.WriteLine(y.CompareTo(x)); // positive one
Console.WriteLine(StringComparer.InvariantCulture.Compare(x, y)); // positive one
Console.WriteLine(StringComparer.InvariantCulture.Compare(y, x)); // positive one
var ja = StringComparer.Create(new CultureInfo("ja-JP", false), false);
Console.WriteLine(ja.Compare(x, y)); // positive one
Console.WriteLine(ja.Compare(y, x)); // positive one
}
You see that x
is strictly greater than y
, and y
is strictly greater than x
.
Because x.CompareTo(x)
and so on all give zero (0
), it is clear that this is not an order. Not surprisingly, I get unpredictable results when I Sort
arrays or lists containing strings like x
and y
. Though I haven't tested this, I'm sure SortedDictionary<string, WhatEver>
will have problems keeping itself in sorted order and/or locating items if strings like x
and y
are used for keys.
Is this bug well-known? What versions of the framework are affected (I'm trying this with .NET 4.0)?
EDIT:
Here's an example where the sign is negative either way:
x = "u4E00u30A0"; // equiv: "一?"
y = "u4E00u002Du0041"; // equiv: "一-A"
question from:
https://stackoverflow.com/questions/13254153/bug-in-the-string-comparing-of-the-net-framework 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…