You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RustPCodeEmitProxy::dump passes the slice start pointer and length to Rust, which converts it into a slice with vars: &[sleigh_sys::ffi::VarnodeData]. The VarnodeData type is declared as a zero-sized type for cxx FFI, however, and not a struct of the same size as what the C++ side has: this means that when you loop over the slice in Rust, each element is actually the start pointer length times, since it advances by 0 each time. This is visible in black-binary/sleigh#1 for example, where each varnode for the store operation is the address space varnode instead of [address space, pointer, data] like it should be.
I have a fork where I fixed the issue by having the C++ layer return a vars: &[&sleigh_sys::ffi::VarnodeData] instead, since advancing by pointer size is fine and allows it to continue using a ZST FFI type. It's mixed in with other things I added when messing around, however, and needs to be pulled out individually: chc4@498daa1chc4/sleigh@3011940
The text was updated successfully, but these errors were encountered:
RustPCodeEmitProxy::dump
passes the slice start pointer and length to Rust, which converts it into a slice withvars: &[sleigh_sys::ffi::VarnodeData]
. The VarnodeData type is declared as a zero-sized type for cxx FFI, however, and not a struct of the same size as what the C++ side has: this means that when you loop over the slice in Rust, each element is actually the start pointer length times, since it advances by 0 each time. This is visible in black-binary/sleigh#1 for example, where each varnode for the store operation is the address space varnode instead of [address space, pointer, data] like it should be.I have a fork where I fixed the issue by having the C++ layer return a
vars: &[&sleigh_sys::ffi::VarnodeData]
instead, since advancing by pointer size is fine and allows it to continue using a ZST FFI type. It's mixed in with other things I added when messing around, however, and needs to be pulled out individually: chc4@498daa1 chc4/sleigh@3011940The text was updated successfully, but these errors were encountered: