Skip to content

Conversation

@GrabYourPitchforks
Copy link
Member

Fix #33596. We added the appropriate early-exit for IndexOfOrdinal but missed it for LastIndexOfOrdinal.


if (value.Length == 0)
{
return Math.Max(0, startIndex - count + 1);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is because the behavior of LastIndexOf is nutty. See the comment below (lifted from PR #1514) for more info.

* For LastIndexOf specifially, overloads which take a 'startIndex' and 'count' behave differently
* than their IndexOf counterparts. 'startIndex' is the index of the last char element that should
* be considered when performing the search. For example, if startIndex = 4, then the caller is
* indicating "when finding the match I want you to include the char element at index 4, but not
* any char elements past that point."
*
* idx = 0123456 ("abcdefg".Length = 7)
* So, if the search string is "abcdefg", startIndex = 5 and count = 3, then the search space will
* ~~~ be the substring "def", as highlighted to the left.
* Essentially: "the search space should be of length 3 chars and should end *just after* the char
* element at index 5."
*
* Since this behavior can introduce off-by-one errors in the boundary cases, we allow startIndex = -1
* with a zero-length 'searchString' (treated as equivalent to startIndex = 0), and we allow
* startIndex = searchString.Length (treated as equivalent to startIndex = searchString.Length - 1).
*
* Note also that this behavior can introduce errors when dealing with UTF-16 surrogate pairs.
* If the search string is the 3 chars "[BMP][HI][LO]", startIndex = 1 and count = 2, then the
* ~~~~~~~~~ search space wil be the substring "[BMP][ HI]".
* This means that the char [HI] is incorrectly seen as a standalone high surrogate, which could
* lead to incorrect matching behavior, or it could cause LastIndexOf to incorrectly report that
* a zero-weight character could appear between the [HI] and [LO] chars.

@GrabYourPitchforks
Copy link
Member Author

@dotnet-bot help

@GrabYourPitchforks
Copy link
Member Author

@dotnet-bot test runtime (Libraries Test Run checked coreclr Windows_NT x64 Debug)
@dotnet-bot test runtime (Libraries Test Run checked coreclr Windows_NT x86 Release)

@GrabYourPitchforks
Copy link
Member Author

/azp list

@GrabYourPitchforks
Copy link
Member Author

/azp run runtime (Libraries Test Run checked coreclr Windows_NT x86 Release)
/azp run runtime (Libraries Test Run checked coreclr Windows_NT x64 Debug)

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

@GrabYourPitchforks
Copy link
Member Author

Don't worry, bots. I still love you. ❤️

@GrabYourPitchforks
Copy link
Member Author

/azp run runtime

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ghost
Copy link

ghost commented Mar 15, 2020

Hello @GrabYourPitchforks!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit a46a792 into dotnet:master Mar 15, 2020
@GrabYourPitchforks GrabYourPitchforks deleted the upd_lio branch March 15, 2020 03:53
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Debug.Assert causing unit test failures in System.Runtime and System.Memory

2 participants