Fix sending MidiPacket when MidiPacket has been created using a point… by jamesdlow · Pull Request #18981 · dotnet/macios (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation33 Commits5 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Fix sending MidiPacket when MidiPacket has been created using a pointer to a byte[] rather than a byte[] passed as a reference.
MidiPacket.bytes is intiailized to a Array.Empty so it is never null, and so packet.BytePointer is never used.
We therefore need to check for ByteArray.Length being 0.
Midipacket.bytes is never 0 when intiailized to a 0 length byte[] as that constructor checked for 0 length byte[]
…er to a byte[] rather than a byte[] passed as a reference.
MidiPacket.bytes is intiailized to a Array.Empty so it is never null, and so packet.BytePointer is never used. We therefore need to check for ByteArray.Length being 0. Midipacket.bytes is never 0 when intiailized to a 0 length byte[] as that constructor checked for 0 length byte[]
Azure Pipelines successfully started running 1 pipeline(s).
@jamesdlow would you be able to create a self-contained test case for this (not using managed-midi)?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Azure Pipelines successfully started running 1 pipeline(s).
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Marking as do-not-merge until we have tests, since this particular piece of code has regressed multiple times already.
⚠️ Your code has been reformatted. ⚠️
If this is not desired, add the actions-disable-autoformat label, and revert the reformatting commit.
If files unrelated to your change were modified, try reverting the reformatting commit + merging with the target branch (and push those changes).
@microsoft-github-policy-service agree
Azure Pipelines successfully started running 1 pipeline(s).
💻 [CI Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻
✅ All tests on macOS M1 - Mac Ventura (13.0) passed.
Pipeline on Agent
Hash: [PR build]
💻 [CI Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻
✅ All tests on macOS M1 - Mac Big Sur (11.5) passed.
Pipeline on Agent
Hash: [PR build]
✅ API diff for current PR / commit
Legacy Xamarin (No breaking changes)
iOS(no change detected)tvOS(no change detected)watchOS(no change detected)macOS(no change detected) NET (empty diffs)iOS: (empty diff detected)tvOS: (empty diff detected)MacCatalyst: (empty diff detected)macOS: (empty diff detected)
✅ API diff vs stable
Legacy Xamarin (No breaking changes)
- iOS: vsdrops gist (No breaking changes)
- tvOS: vsdrops gist (No breaking changes)
- watchOS: vsdrops gist (No breaking changes)
- macOS: vsdrops gist (No breaking changes) .NET (No breaking changes)
- iOS: vsdrops gist (No breaking changes)
- tvOS: vsdrops gist (No breaking changes)
- MacCatalyst: vsdrops gist (No breaking changes)
- macOS: vsdrops gist (No breaking changes)
- Microsoft.iOS vs Microsoft.MacCatalyst: vsdrops gist Legacy Xamarin (stable) vs .NET
- iOS: vsdrops gist
- tvOS: vsdrops gist
- macOS: vsdrops gist
ℹ️ Generator diff
Generator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes)
Pipeline on Agent
Hash: 07191dfb688d6b3f9de324002661f0b353a65e03 [PR build]
/sudo backport release/8.0.1xx
Backport Job to branch release/8.0.1xx Created! The magic is happening here
rolfbjarne pushed a commit that referenced this pull request
…ated using a point. (#19716)
Fix sending MidiPacket when MidiPacket has been created using a pointer to a byte[] rather than a byte[] passed as a reference. MidiPacket.bytes is intiailized to a Array.Empty so it is never null, and so packet.BytePointer is never used. We therefore need to check for ByteArray.Length being 0. Midipacket.bytes is never 0 when intiailized to a 0 length byte[] as that constructor checked for 0 length byte[]
Backport of #18981
Co-authored-by: James Low j@jameslow.com