API soundness issue in join() implementation of [Borrow<str>]
Qwaz opened this issue · 2 comments
A weird Borrow
implementation that returns a different result for each call can create a string with uninitialized bytes with join() implementation of [Borrow<str>]
type.
The problem is in join_generic_copy
function.
-
The borrow result is first used for the length calculation.
Lines 152 to 161 in 3ffea60
-
Then, inside
spezialize_for_lengths
macro, the user-provided slice is borrowed again and the content is copied.
Lines 110 to 114 in 3ffea60
-
Finally, the length of the slice is set to the length calculated in step 1.
Line 179 in 3ffea60
Playground link, which demonstrates creating a non-UTF-8 string by only using safe Rust.
Assigning P-high
as discussed as part of the Prioritization WG procedure.
I guess all that’s needed is an assert!(target.is_empty())
at the end of the body of the spezialize_for_lengths
macro? Perhaps the typo in its name could be fixed, too. It might also be beneficial to avoid the unnecessary third(!) call to borrow()
that’s due to copy_slice_and_advance
using its second argument twice.