Implement DataNotification for rust

[rbran]

[emesare]

The solution for only registering the notifications is fine with me, I will be able to review this more once testing is done for the upcoming 5.0 release. Thank you!

[emesare]

When constructing the data notification it is very important that we not copy/clone the BNBinaryDataNotification otherwise when we go to unregister the notifications we will be keying off a different object. I understand this is more of an issue with the FFI layer keying off something such as the pointer value but we should still support unregistering it. In the branch below I just wrap the BNBinaryDataNotification constructed in register_data_notification with a Box and move the boxed value into the returned DataNotificationHandle.

https://github.com/Vector35/binaryninja-api/blob/ddad75346f5ecf81768c9c1139909ed8afcb9eab/rust/src/data_notification.rs#L92-L103

[greaka]

If I understand your comment correctly, then you are doing a pointer equality check during deregister? In that case a Box is not enough, you need a Pin:

- let mut boxed_handle = Box::new(handle); 
+ let mut boxed_handle = Box::pin(handle); 

register_data_notification already introduced the lifetime 'a and binds both H and the output to it. Why do you want to require owning self too in this case? By changing the function signature to something more like the following, you could allow to still use the original struct instance outside of notifications.

    fn register_data_notification<'a, H: CustomDataNotification + 'a>(
        view: &BinaryView,
        notify: &'a H,
        triggers: DataNotificationTriggers,
    ) -> DataNotificationHandle<'a, H> {}

    fn register<'a>(
        &'a self,
        view: &BinaryView,
        triggers: DataNotificationTriggers,
    ) -> DataNotificationHandle<'a, Self> where Self: 'a + Sized {
        register_data_notification(view, self, triggers)
    }

if you require Pin:

    fn register_data_notification<'a, H: CustomDataNotification + 'a>(
        view: &BinaryView,
        notify: Pin<&'a H>,
        triggers: DataNotificationTriggers,
    ) -> DataNotificationHandle<'a, H> {}

    fn register<'a>(
        self: Pin<&'a Self>,
        view: &BinaryView,
        triggers: DataNotificationTriggers,
    ) -> DataNotificationHandle<'a, Self> where Self: 'a + Sized {
        register_data_notification(view, self, triggers)
    }

With a few extra lines you could then also support ?Sized implementers. You need to support saving the original fat pointer to make that work.

One alternative would be to add support for fetching the original Self via a getter on DataNotificationHandle, I'm not sold on that idea yet though.

[emesare]

If I understand your comment correctly, then you are doing a pointer equality check during deregister? In that case a Box is not enough, you need a Pin:

Yea thanks for the correction, we want to pin the boxed value. Will make sure to swap out the call before merging.

[rbran]

If I understand your comment correctly, then you are doing a pointer equality check during deregister? In that case a Box is not enough, you need a Pin:

I can't see how the value could be moved leaving the original pointer invalid, specially because the Box is leaked immediately and only the type implementation itself will operate on the data ref. Let me know of an example where that can happen if you know some.

register_data_notification already introduced the lifetime 'a and binds both H and the output to it. Why do you want to require owning self too in this case?

That's a really good idea, I did that in fact, the only difference is that CustomDataNotification::register is the easy-to-use function for Unpin (99% of the cases) impl types and register_data_notification for anything else that needs Pin.

With a few extra lines you could then also support ?Sized implementers. You need to support saving the original fat pointer to make that work.

That will require a significant amount of complexity, I think that's better left for the user to implement manually, aka put the type in a Box, mostly because is very unlikely we will see a UnSized type used here.

[emesare]

Apologies for this taking forever, thank you @rbran for the PR and @greaka for your input!