Description
I'll try to write down the concerns about ndarray's unsafe code that I know about. In many cases this is about aligning better with the developing unsafe code guidelines for Rust, which have been in progress for a long time. It is possible to adopt best practices and fixes, before these guidelines are finished.
ndarray is written carefully and has had many incremental improvements to its internals, but like much unsafe Rust code in the wild, it's unavoidable that our authors's model of unsafe Rust might not correspond to the consensus and best practices of Rust right now. So we try to list concerns and improve piece by piece.
If you know a clear-cut soundness bug with a scope-limited fix, it can be reported directly as a separate bug and does not need to be listed here. Specific concerns in this issue should be researched more deeply before they are fleshed out and fixed in pull requests.
Uninitialized data 1
Possibly fixed by #798. Examples fixed by #805
Concern description
Some examples and some internal code suppose we can use &mut T to overwrite in unitialized data, but it is unclear if this is correct.
Possible remedy
Use raw views and traversal with raw pointers - now possible with Zip to overwrite unitialized elements
Uninitialized data 2
See issue #685
Partly mitigated by #802
Concern description
Is the uninitialized data constructor for Arrays the right API? Does it make sense to expose it, and how do we do it in a safe way?
As food for thought, consider that Vec::with_capacity(128) is a well-known and safe abstraction for dealing with unitialized data - in this case 128 elements of that - can we use this thinking for our arrays.
Ownership and aliasing through Raw Pointers
Fixed by #799
Concern description
The unique and shared ownership arrays have two access ways to the data - through self.ptr and through the owned data's pointer accessor. The Vec assumes unique ownership of its data (like the Box), so having an aliasing extra pointer is possibly problematic.
Possible remedy
When creating an Array from a Vec, "take apart" the Vec into data pointer, len, capacity and don't store it as a Vec but in a representation that shows the compiler that we no longer assert unique ownership through the Vec's data pointer.
Details and possible remedy for Arc<Vec<_>> are not known.
Further info
In principle, this problem is described in issue Kimundi/owning-ref-rs#49