Trait BinaryViewTypeExt
pub trait BinaryViewTypeExt: BinaryViewTypeBase {
// Provided methods
fn name(&self) -> String { ... }
fn long_name(&self) -> String { ... }
fn register_arch<A: Architecture>(
&self,
id: u32,
endianness: Endianness,
arch: &A,
) { ... }
fn register_platform(&self, id: u32, plat: &Platform) { ... }
fn register_platform_recognizer<R>(
&self,
id: u32,
endian: Endianness,
recognizer: R,
)
where R: 'static + Fn(&BinaryView, &Metadata) -> Option<Ref<Platform>> + Send + Sync { ... }
fn open(&self, data: &BinaryView) -> Result<Ref<BinaryView>> { ... }
fn parse(&self, data: &BinaryView) -> Result<Ref<BinaryView>> { ... }
}Source
Expanded identification of Platform for BinaryViewType’s. Supersedes BinaryViewTypeExt::register_arch
and BinaryViewTypeExt::register_platform, as these have certain edge cases (overloaded elf families, for example)
that can’t be represented.
The callback returns a Platform object or None (failure), and most recently added callbacks are called first
to allow plugins to override any default behaviors. When a callback returns a platform, architecture will be
derived from the identified platform.
The BinaryView is the parent view (usually ‘Raw’) that the BinaryView is being created for. This
means that generally speaking the callbacks need to be aware of the underlying file format, however the
BinaryView implementation may have created datavars in the ‘Raw’ view by the time the callback is invoked.
Behavior regarding when this callback is invoked and what has been made available in the BinaryView passed as an
argument to the callback is up to the discretion of the BinaryView implementation.
The id ind endian arguments are used as a filter to determine which registered Platform recognizer callbacks
are invoked.
Support for this API tentatively requires explicit support in the BinaryView implementation.
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.