Conversation
Stargateur
left a comment
Stargateur
left a comment
There was a problem hiding this comment.
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.
I think it's fine but not sure.
There was a problem hiding this comment.
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.
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. |
3 participants
I recently ran into a situation where a tool I help maintain and
tcpdumphad different behavior with a somewhat exotic libpcap implementation. I eventually tracked this down to the fact thattcpdumpusespcap_loopand 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_loopfrom 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.