I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap
exports and manual.
I've added pcap_dump_ftell(), and I've tested everything with the today
tcpdump sources: -C now works correctly on Windows.
I had to make a small fix to the DSP of tcpdump in order to have
print-dhcp6.c compile correctly: I've already checked it in the
tcpdump.org cvs.
Just a small note: pcap_dump_ftell() returns a long, which on most
platforms (including Windows64) is a 32-bit value. I think this could
cause problems with capture files bigger than 4 Gigabytes, which by the
way will be explicitly supported by the new capture format. What about
returning a u_int64_t?
Loris
Guy Harris wrote:
On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote:
Consistency of the API across different platforms, taking into
consideration that some of them could have serious rerstrictions, is
an advantage for everybody, developer's and maintainers. Not only
Chris Lightfoot. And has always been the main strenght of libpcap and
tcpdump.
...as long as consistency doesn't mean that Microsoft's limitation
doesn't constrain UN*X-only applications (and UN*X limitations don't
constrain Windows-only applications). I suspect Chris might not be the
only person who's wanted to do that.
At least, let's try to make it very clear which part of the API will
be usable everywhere: I've worked quite hard to improve this side of
the WinPcap 3.1 manual.
That sounds reasonable. I can update the man page to say those
functions can only be used on Windows for binaries built with the same
C runtime as WinPcap - or we could just make them UN*X-only.
And, I still think that pcap_dump_ftell() could be useful.
I agree, which is why I just checked in a pcap_dump_ftell()
implementation, and changes to tcpdump to use it (and to supply its own
implementation, which "knows" that a "pcap_dumper_t *" is a "FILE *",
for use with older libpcaps; in those older libpcaps, a "pcap_dumper_t
*" is a "FILE *").
It's pretty unelegant (and risky) to export an opaque pcap_dumper_t
structure and then assume that the user will cast it to a FILE*...
It's completely *bogus* to do that, which is why tcpdump should be (and
was) changed not to cast it (except in its own pcap_dump_ftell()
implementation, if libpcap doesn't have one).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
