OpenBSD's pflogd use it to reach inside a struct pcap, which is a structure that's subject to change, possibly in ways that will cause pflogd not to work. I will not do anything to encourage programs to reach inside that structure, as I will not do anything that will encourage people to whine that I'm breaking a published interface by changing it. OpenBSD has its own libpcap; they're welcome to export pcap-int.h in OpenBSD if they choose.

OpenBSD's tcpdump uses it only to compile a filter expression into BPF code. The comments say

    /* fake hpcap, it only needs errbuf, snaplen, and linktype to
     * compile a filter expression */

and even explicitly acknowledge that they're doing a Bad Thing:

    /* XXX messing with pcap internals */

What they need is pcap_open_dead(), which allows you to create a fake pcap_t with a specified snaplen and linktype; you can then pass it to pcap_compile() and, if that fails, extract the error message from the fake pcap_t before closing it. (It's a bit of an ugly API - what's really called for is a function that takes the filter string, linktype, and snaplen as input arguments, and the BPF program and error buffer as output arguments.)

pypcap uses it to

1. reach inside the pcap_t _IF_ libpcap doesn't have pcap_file(), but the version we provide does have it, so it doesn't need to reach inside the pcap_t;
2. get struct pcap_file_header defined, which we could do simply by moving it to pcap.h, although that might encourage people write their own code to access pcap files and thus end up with programs that can't handle pcapng files (which will probably become more and more common over time, especially once I end up adding full support for reading them, and support for writing them, to libpcap).

What are you using pcap-int.h - a file that contains "-int", which means "internal", as in "this file contains internal details of the pcap implementation that aren't public and are subject to change from release to release" - for?

Thanks for the clarification. I'm doing the same what pflogd does - fiddling with the pcap struct. Now that I know your reasons for leaving it out of user's reach, I agree with you.

Some of what pflogd does can already be done with existing APIs - it can fetch the snapshot length with pcap_snapshot() and the link-layer header type with pcap_datalink().

Getting the tzoff value can't, but that value isn't actually used by anybody (because it can't be fetched). Recording time zone information in a capture file requires a bit more thought - arguably what it should record is something like an IANA tzdb zone identifier, so that the program reading it can determine what the offset from UTC and daylight savings time rules are.

I'm not sure why it's setting the snaplen, but there might be a better way of accomplishing what it's trying to do there. I'll need to look at that some more.

It's also getting struct pcap_file_header; if it's writing pcap files with its own code, that's OK, and maybe moving that structure to pcap.h would make sense, although it's worth seeing whether the pcap_dump_ APIs could be used.

For posterity, there is now a FAQ entry about this.