bad midi input creates unrecoverable (?) panic

[amomentunfolding]

Hi there!
One of my MIDI keyboards (Midiplus X-6 III) seems to always send some funky data when it first connects.
The coremidi backend is quite unhappy about it and panics and crashes my whole program, I have tried adding catch_unwind in various places as a workaround but I can't seem to stop it from crashing things even with that.

For now I just restart my program and then it works as expected, the keyboard only sends this during its first message of the power cycle.
Perhaps just a size check before accessing the slice (src/backend/coremidi/mod.rs:160:51) will do the trick.
I reckon this is quite specific to this device (but strange hardware wonkyness probably isnt) and hard for others to reproduce, I will try to figure it out but thought I'd raise it here as well for eventual comment.

thread '<unnamed>' panicked at /Users/XXXX/.cargo/registry/src/index.crates.io-6f17d22bba15001f/midir-0.10.0/src/backend/coremidi/mod.rs:160:51:
range end index 3 out of range for slice of length 1
[ursund::midi][INFO] midi from X6III MidiOut: NoteOn(Ch1, G3(55), U7(33))
[ursund::midi][INFO] midi from X6III MidiOut: NoteOff(Ch1, G3(55), U7(0))
[ursund::midi][WARN] midi error from X6III Port 2: UnexpectedStatusByte
[ursund::midi][INFO] midi from X6III Port 2: ActiveSensing
stack backtrace:
   0:        0x104f19b33 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9e09877065e04f77
   1:        0x104f410bb - core::fmt::write::ha1eda037e545f7da
   2:        0x104f1600e - std::io::Write::write_fmt::h982a70ce7879c870
   3:        0x104f19921 - std::sys_common::backtrace::print::h614a07b8de11add7
   4:        0x104f1adf9 - std::panicking::default_hook::{{closure}}::h079cbc758586c627
   5:        0x104f1ab60 - std::panicking::default_hook::ha4241b247d28f540
   6:        0x104f1b82e - std::panicking::rust_panic_with_hook::h610a5d47d992d59c
   7:        0x104f1b194 - std::panicking::begin_panic_handler::{{closure}}::hb7bd4ff0d901d687
   8:        0x104f1a009 - std::sys_common::backtrace::__rust_end_short_backtrace::h08de5c5c123a7cab
   9:        0x104f1aec6 - _rust_begin_unwind
  10:        0x104f7b165 - core::panicking::panic_fmt::h2c2c8066e5becbb9
  11:        0x104f431b6 - core::slice::index::slice_end_index_len_fail_rt::hac8ef25b6ed6fa6b
  12:        0x104f7b689 - core::slice::index::slice_end_index_len_fail::h733ed5de050a9e19
  13:        0x104877b5f - midir::backend::coremidi::MidiInput::handle_input::h2267dac3d72f574f
  14:        0x104880147 - <X as block::IntoConcreteBlock<(A,B)>>::into_concrete_block::concrete_block_invoke_args2::h78af1e8f12ca998d
  15:     0x7fff315cc19d - __ZN21LocalMIDIReceiverList12HandleMIDIInEjjPvPK14MIDIPacketList
  16:     0x7fff315cc057 - __ZN11MIDIProcess15RunMIDIInThreadEv
  17:     0x7fff315cacde - __ZN7XThread9RunHelperEPv
  18:     0x7fff315ae191 - __ZN9CAPThread5EntryEPS_
  19:     0x7fff6a674109 - __pthread_start
fatal runtime error: Rust panics must be rethrown

[Boddlnagg]

I guess we could just read all bytes up until the end of the slice if not enough bytes are available to read size bytes. Can you test that locally (should be quite easy using a Cargo override) and see if everything works for you then?
I agree that there's probably plenty of bad hardware out there and we should handle it gracefully.

[Boddlnagg]

@amomentunfolding Have you been able to verify that reading up to the end of the slice if not enough bytes are available works in your situation?