Guy Harris

> The other 10% is, I think, the applications that expect pcap_dumper_t to be a FILE*, and maybe they are just broken. The main reason why they might do that...

> I hate "ng" and I wish we didn't embed that... because "NEXT" is always coming. I'm not committed to "ng", just as long as we change the name.

> Are you saying that pcap_open_live() is a #define? No, it's a wrapper around `pcap_create()` and `pcap_activate()`, but it does `p->oldstyle = 1;` before calling `pcap_activate()` because, as the comment...

Changing the ABI is a bit bigger issue for Solaris and macOS, where binary compatibility is expected by third-party developers.

> Should we keep rpcapd code in the libpcap repository? Not doing so would require putting the common rpcap protocol headers and code somewhere, whether: - into libpcap itself; -...

OK, it's *supposed* to be defined automatically by CMake, according to [the documentation for the `DEFINE_SYMBOL` property](https://cmake.org/cmake/help/latest/prop_tgt/DEFINE_SYMBOL.html): > Define a symbol when compiling this target’s sources. > > DEFINE_SYMBOL sets...

Were you overriding `LIBRARY_NAME` with a `-D` option to CMake, or did you have to modify `CMakeLists.txt`? If you had to modify `CMakeLists.txt`, that needs to be fixed.

So does applying change 4d490932e08daefa778f58ea4694fc97486507ce to the 1.9.0 `CMakeLists.txt` work?

We no longer have `pcap_snprintf()` in the trunk; just use `snprintf()`, as we only support building on platforms (OS+compiler) that support it.

APIs that affect contents of the private data pointed to by the `priv` member of a `pcap_t` should not be called directly - they should be called through a pointer...