Emerentius
commented
7 years ago Yes, you're right. I wanted to fix this for a while now, but had no access to a pc until yesterday. Great timing on the bug.
There is no unsafe{} in this library. A call to .cmp() may crash and chained if-else statements using >, =, < and such may give you the wrong answer but nothing that causes memory unsafety unless someone relies on that in unsafe code and then it's on them as per the nomicon.
In the documentation for ord_subset::OrdVar::new_unchecked it says:
Constructs an OrdVar without validity check. Incorrectly constructed OrdVars may panic during comparisons. This is the only way to construct an OrdVar out of a type that is not OrdSubset.
And it is marked unsafe. It is currently unclear what the unsafe behavior is here.
panicing is not unsafe, so if comparisons either succeed or panic then probably nothing should be marked unsafe in this crate. If comparisons (or other functionality) can do something other than succeed or panic, then that behavior should be noted in the documentation along with info on how to ensure correct behavior when using the unsafe features.