Closed c3rb3ru5d3d53c closed 1 week ago
Nightly only appeared to have failed due to an unrelated cargo update segmentation fault, not sure why that is the case, all other tests appear to pass.
@c3rb3ru5d3d53c thanks for your PR! Sorry I have not had time to review the PR (yet). Also, I allowed the rest of the tests to run--there are some tests failing.
I think what you want is provided by the OwnedInsn
type which avoids holding a reference.
You can see an example in the test_owned_insn()
function:
https://github.com/capstone-rust/capstone-rs/blob/62c7ec570451b5cc0cdf8761ebb0fb95b60f8a64/capstone-rs/src/test.rs#L3319-L3332
I'll close this PR for now, but feel free to comment on it if you think it should be re-opened.
Typically, when writing more complex code using
capstone
we can collectcs_insn
structures on their own.For example, we can create a list of
cs_insn
structures in Python without them going out of scope.Currently this is not appearing to be possible in
capstone-rs
because theInsn
andcs_insn
structures only being accessed by reference when contained inInstructions
iterator.Most of the work on implementing the
clone
functionality has already been done forcs_detail
structure and others.This PR simply implements
clone
for bothcs_insn
andInsn
structures, so it is possible to store these for later use in more complex projects.Here is an example of using this functionality:
It also helps for when we need to iterate a single instruction at a time collecting them for later post-processing.
This becomes an issue when having to unpack from the
Instructions
iterator and only getting references without the possibility of cloning for later use.This should not break any other features, it simply continues what was already done with
cs_detail
and other placesclone
has already been implemented in thecapstone-rs
project.That being said, this is my first Rust-based PR, so proceed with caution.
Thank you :smile: