-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a binding for pcap_loop #310
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
name it run (commun for loop in rust lib) instead of loop maybe, but I don't like the pcap in front for sure.
self.handle.as_ptr(), | ||
0, | ||
Handler::<F>::callback, | ||
ptr::addr_of_mut!(handler).cast(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine but not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean to comment on here. Perhaps you mean ptr::addr_of_mut!
? If the place it's passed has no projections, then there are no preconditions. And you can even addr_of!(*ptr)
for any ptr
: rust-lang/reference#1387
src/lib.rs
Outdated
impl<T: State + ?Sized> Capture<T> { | ||
pub fn pcap_loop<F>(&mut self, handler: F) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this method is unsafe by nature, since it's will call rust from C
Due to significant changes on |
sigh I force-pushed to the branch before re-opening the PR which has killed the PR. I'll open a fresh one. |
I recently ran into a situation where a tool I help maintain and
tcpdump
had different behavior with a somewhat exotic libpcap implementation. I eventually tracked this down to the fact thattcpdump
usespcap_loop
and since said tool is going through this crate, it was usingpcap_next_ex
. This difference was actually a bug in the libpcap implementation, I spent a frustrating amount of time convincing people that the bug was in libpcap, because I couldn't closely imitate the libpcap calls oftcpdump
.Since that time, I've been wanting a way to call
pcap_loop
from this crate, because that would have made my life a lot easier. So I finally got around to putting one together, here it is.I don't really care about the public API. Ideas like a better name are very welcome.