Lib.rs

Has unsoundness in a major, safe interface.

The main utility for Vec can reuse an allocation of differing element size thus violating the explicit requirements of Vec::from_raw_parts and in particular the allocator contract, potentially leading to memory corruption on drop of the resulting Vec.

The interface affected are (maybe not complete):

• MapVecInPlace::map
• MapVecInPlace::map_in_place
• MapVecInPlace::filter_map
• MapVecInPlace::filter_map_in_place

An analysis of the code to show the issue:

In a macro, this code checks for various size and alignment constraints on deciding whether to execute an in-place branch or a fallback (that may panic in some variants).

unsafe { if size!($a) == 0 || size!($b) == 0 { $zero } else if align!($a) != align!($b) { $alignment } else if $f(size!($a),size!($b)) { $incompatible } else { $ok } }

Already a naming issue appears, as the $incompatible branch is actually taken when f returns true and some instantiation has |a,b| a==b as this argument. Consequently, the incompatible parameter is filled with the in-place branch in the fallback branch where the parameter is $ok:expr

Note that the check for map is |a,b| a%b==0 and it invokes $fallback with the $ok:expr argument set to map_vec(self, f) (note: the f here is from the parameters of map). The map_vec function is an unsafe function eventually doing the equivalent of

let (ptr, len, cap) = /* The obvious */; // Some transformation code on raw. Vec::from_raw_parts(ptr, len, cap)

This violates very clearly the contract which states:

ptr's T needs to have the same size and alignment as it was allocated with