Open LiquidityC opened 3 years ago
Problem with using VecDeque
is that you cannot get a continuous slice of bytes from it without making an explicit call to VecDeque::make_contiguous
first. I'm open to having VecDeque
-backed storage under a feature flag, but if the security bug is impossible to trigger from minimp3
, I'm not sure if I want it as the default.
Is there a way to patch the slice_deque
crate?
Looking at the very well defined issue in linked above, the problem does look like a trivial fix. It's the fact that the maintainer chose not to respond for over a month that makes me think he's busy with other things and not actively maintaining SliceDeque
.
I can take a swing at fixing the actual issue. Otherwise we'll have to hope that someone takes up the mantel or forks the project and maintains it.
I'll try for a PR and see where we end up. I get that VecDeque
isn't really a good option here.
I sent a PR, gnzlbg/slice_deque#91. Let's see how it evolves.
I gave up on waiting for the maintainer of SliceDeque
. There is now a maintained fork here: https://crates.io/crates/slice-ring-buffer
Would you like a PR?
Hello,
as explained in this issue: gnzlbg/slice_deque#90, depending on the crate
SliceDeque
will fail builds that run thecargo audit
command.Would it be possible to circumvent this dependency with
VecDeque
or similar since the maintainer ofSliceDeque
seems to be unresponsive? From my understandingVecDeque
isSend
so switching would also remove anunsafe
impl in the codebase.I could take a swing at this but for some reason I'm having problems building the project right now.