String.EndsWith on CoreCLR \ Linux does not work correctly for line feeds

[pranavkm]

Here's the repro example:

using System;

public class Program
{
    public static void Main (string[] args)
    {
        var text = "Hello\r\n";

        Console.WriteLine(text.EndsWith("\n"));
        Console.WriteLine(text.LastIndexOf('\n') == text.Length -  1);
    }
}

Expected: True True
Actual: False True

I used DNX v1.0.0-rc2-16216 to run this application. The version of System.Console I used was 4.0.0-beta-23516. Running it with DNX Mono or running this on Windows produces the right results.

[stephentoub]

Related to https://github.com/dotnet/corefx/issues/3467 and https://github.com/dotnet/coreclr/issues/2051.

[ellismg]

In this specific case, using StringComparision.Ordinal (to force Ordinal comparison) should address the issue until the code is fixed. It also turns out that doing so will give you better performance as Ordinal comparisions (which is what you want here) are faster than linguistic comparisions.

[pranavkm]

👍 We switched to looking at the underlying chars in our code since we were needlessly creating the string from a StringBuilder

[ellismg]

@pranavkm Event better!

[pranavkm]

Feel free to close this bug if the issue is independently tracked.

[stephentoub]

@ellismg, @joshfree, this is marked as 1.1.0... should it be moved back to 1.0.0-rtm?

[tarekgh]

@pranavkm I cannot reproduce this issue. could you please try it and let me know if you still see the problem?

[tarekgh]

To conclude this issue and clarify the expected behavior:

• When doing linguistic collation operations, it is expected you'll see different behavior when running on Linux than Windows. the reason is net core is just calling the OS for such operations.
• For this specific case when search for "\n" in a string has "\r\n", this one of the differences between Windows and Linux. ICU collation will treat "\r\n" differently and not as 2 separate characters '\r' and '\n'. so searching linguistically for \n will fail to find it on Linux. If you remove \r from the original source and search for \n, that will succeed.
• In general if you are searching for \n, \r or similar character categories, It is recommended to use ordinal search and not linguistic search.
• We had an issue which is we were trying to optimize the search when having Ascii strings and that was causing a problem of having different behavior when using non-ascii string. we have fixed this problem through the linked PR.

Please let me know if you have any question. Thanks.