Given documentation for string.StartsWith
and this snippet (targeting .net core 2.x):
This method compares the value parameter to the substring at the beginning of this string that is the same length as value, and returns a value that indicates whether they are equal. To be equal, value must be an empty string (String.Empty), must be a reference to this same instance, or must match the beginning of this instance. This method performs a comparison using the specified casing and culture.
https://learn.microsoft.com/en-us/dotnet/api/system.string.startswith?view=netcore-2.1
static void Main(string[] args)
{
var unicodeCtrl = "\u0000";
var str = "x";
Console.WriteLine($"Is it empty => {unicodeCtrl == string.Empty}");
Console.WriteLine($"Lenghts => {str.Length} {unicodeCtrl.Length}");
Console.WriteLine($"Are they equal => {str == unicodeCtrl}");
Console.WriteLine($"Are they ref eq => {Object.ReferenceEquals(str, unicodeCtrl)}");
Console.WriteLine($"Contains => {str.Contains(unicodeCtrl)}");
Console.WriteLine($"Starts with => {str.StartsWith(unicodeCtrl)}");
}
It produces expected result on Windows:
Is it empty => False Lenghts => 1 1 Are they equal => False Are they ref eq => False Contains => False Starts with => False
but when run on Linux (via docker) the result is:
Is it empty => False Lenghts => 1 1 Are they equal => False Are they ref eq => False Contains => False Starts with => True
Would you consider this a bug?
Platform dependent behavior?
Please note I'm not asking how to make it work (change to str.StartsWith(unicodeCtrl,StringComparison.OrdinalIgnoreCase)
)
but rather if you believe this is intended/correct behavior.
Edit: I tried to match my local locale on Linux, but it did not make a difference. I tried default C (en-US-POSIX) and pl_PL.UTF8