Lib.rs

› midir › Reviews

This review is from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

The current version of midir is 0.10.1.

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-deploy (implies safe-to-run)

This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…

safe-to-run
Implied by other criteria

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…

This review is from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

The current version of midir is 0.10.1.

0.5.0 (older version) Rating: Negative Thoroughness: Low Understanding: Low

by MaulingMonkey on 2019-09-02

Good starting point, and my favorite Rust MIDI API so far, but likely unsound as stands.

Pros:

  • Pure rust, no mucking with building building C/C++ libs like with portmidi
  • To be WASM/Browser compatible (PR made).

Cons:

  • Likely unsound as currently stands (transmute_copy, type punning, sketchy memalloc crate use, haven't vetted thread safety properly, ...)
  • API clunky in spots (mix of known issues and easily fixed surface level stuff)
  • Needs more unit test coverage if possible (are there perhaps virtual MIDI devices for windows that could be added to CI...?)

TODO:

  • rating: netural: Eliminate as much sketchy unsafe as possible.
  • rating: positive: Clean up API design a bit (async, saner member functions, deal with Send inconsistency, maybe make connecting not consume MidiInput s?)

Detail

File Rating Notes
examples/test_forward.rs +1
examples/test_play.rs +1
examples/test_reuse.rs +1
examples/test_sysex.rs +1
src/backend/asla/mod.rs 0 Some extra unsafe, use of uninit data possibly UB
src/backend/coremidi/mod.rs 0 Is Core MIDI thread safe? (unsafe impl Send for MidiOutputConnection)
src/jack/mod.rs -1 Use of transmute_copy on Box is skeeeeeeetchy, uninitialized too :(
src/jack/wrappers.rs -1 Is JACK thread safe? Ringbuffer::read is unsound! Lots of unsafe but mostly for sane FFI.
src/winmm/handler.rs 0 unsafe for FFI, some pointer casts I haven't thoroughly vetted
src/winmm/mod.rs 0 unsafe for FFI, uninitialized :(, sketchy deallocate API. Is WinMM thread safe? 333: UB &mut violates aliasing?
src/backend/mod.rs +1
src/os/mod.rs +1
src/os/unix.rs +1
src/common.rs 0 Consumption of the MidiInput/MidiOutput clients/factories on connect seems a bit strange, especially after the ports refactor.
src/errors.rs +1
src/lib.rs +1 unsafe, but sound
tests/virtual.rs +1
.cargo-ok +1
.gitignore +1
.travis.yml +1 RCE: Downloads/installs jack from the internet
appveyor.yml +1
Cargo.toml +1
Cargo.toml.orig +1
LICENSE +1
README.md +1
Other Rating Notes
unsafe -1 99% sure something in here is unsound. transmute_copy, type punning, use of memalloc crate.
fs +1 N/A
io 0 libc... maybe safe?
docs +1
tests 0 Good examples, but needs more automated unit/integration tests. Admittedly hard given the lack of MIDI devices on CI servers...

src/backend/asla/mod.rs

Line What Notes
21 fn poll +1
81 unsafe impl Send for EventEncoder Is ASLA thread safe?
578 unsafe in handle_input Construction of uninitialized vec, UB?

Lib.rs has been able to verify that all files in the crate's tarball, except Cargo.lock, are in the crate's repository. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.

Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.

To review the actual code of the crate, it's best to use cargo crev open midir. Alternatively, you can download the tarball of midir v0.10.1 or view the source online.