Skip to content

SplitString: fix platform-dependent newline split, retarget net10.0 - #2167

Open
vladimir-pecanac-main wants to merge 1 commit into
CodeMazeBlog:mainfrom
vladimir-pecanac-main:seo/86541-split-string
Open

SplitString: fix platform-dependent newline split, retarget net10.0#2167
vladimir-pecanac-main wants to merge 1 commit into
CodeMazeBlog:mainfrom
vladimir-pecanac-main:seo/86541-split-string

Conversation

@vladimir-pecanac-main

Copy link
Copy Markdown
Collaborator

Sample for Different Ways to Split a String in C#, which is being republished.

The defect this PR exists for

SplitStringIntoNewLines was called with new[] { Environment.NewLine } against a literal whose only line endings are \n. On Linux that separator is "\n", so the split returns five elements and the test passes. On Windows Environment.NewLine is "\r\n", the input holds no \r, no separator is ever found, and the split returns one element holding the whole string.

WhenSplittingAStringIntoNewLine_ThenReturnArrayOfSubstrings asserted Length == 5 against exactly that, so CI was green on a test that fails on a Windows developer's machine. Measured on this box (SDK 10.0.302) before the fix:

Environment.NewLine bytes: 13,10
OLD (Environment.NewLine) length = 1
NEW (["\r\n", "\n"]) length = 5

Both sides now split on ["\r\n", "\n"], so the assertion is true on every platform rather than on the one the runner happens to use. A second test covers genuinely mixed \r\n / \n input.

Also in here

  • SplitStringUsingStringArrayWithoptions takes a StringSplitOptions parameter defaulting to None, so the existing test keeps its exact behaviour while Main can pass RemoveEmptyEntries on an input that actually has empty entries ("apple,,banana;;kiwi"). The old input had none, so the option it was demonstrating did nothing visible.
  • SplitStringWithOptions plus four tests, covering all four StringSplitOptions results on the runtime's own documented input "a,,b, c, , d ,e". Run on net10.0:
None: [a] [] [b] [ c] [ ] [ d ] [e]
RemoveEmptyEntries: [a] [b] [ c] [ ] [ d ] [e]
TrimEntries: [a] [] [b] [c] [] [d] [e]
RemoveEmptyEntries, TrimEntries: [a] [b] [c] [d] [e]

Note that RemoveEmptyEntries on its own keeps the whitespace-only " ", which is the point of the pair.

  • CountSplitRanges, one method demonstrating ReadOnlySpan<char>.Split into a stack-allocated Span<Range>, which allocates no substrings at all.
  • net6.0 -> net10.0 on both projects. Packages: MSTest.TestAdapter / MSTest.TestFramework 2.2.8 -> 4.3.3, Microsoft.NET.Test.Sdk 17.1.0 -> 18.9.0, coverlet.collector 3.1.2 -> 10.0.1 (all read from the NuGet flat container today).

Verification

Windows, SDK 10.0.302:

Build succeeded.
    0 Warning(s)
    0 Error(s)

Passed!  - Failed: 0, Passed: 13, Skipped: 0, Total: 13, Duration: 53 ms - SplitStringTests.dll (net10.0)

The newline sample split a \n-only literal on Environment.NewLine, so on
Windows it found no separator and returned one element while the test
asserted five. It passed on Linux CI only. Both sides now split on
["\r\n", "\n"], which is honest on every platform.

- SplitStringUsingStringArrayWithoptions takes StringSplitOptions
  (default None) so the sample can demonstrate RemoveEmptyEntries on an
  input that has empty entries.
- Adds SplitStringWithOptions, covering the four StringSplitOptions
  results the article tabulates, and CountSplitRanges, the allocation-free
  ReadOnlySpan<char>.Split into a stack-allocated Span<Range>.
- net6.0 -> net10.0; MSTest 4.3.3, Microsoft.NET.Test.Sdk 18.9.0,
  coverlet.collector 10.0.1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant