On Mon, May 06, 2002 at 04:13:34PM -0400, Carter Bullard wrote:
> I think that if you want this type of interface
> separation, you should at least provide routines
> to return all the various values that are in the struct.
Sounds reasonable - at least for those values that will continue to be
available in future versions.
> While only a few of us would ever use them, that's the
> kind of support that makes packages like libpcap
> useful for a large number of applications, even those
> applications that may be considered odd.
>
> It would be nice to get the device name from the
> struct pcap_md, the timeout value, and the address
> of the struct bpf_program.
Those sound reasonable.
> I understand that you are trying to get some handle
> on backward compatibility, and future extensibility, but
> I would suggest that you distribute pcap-int.h,
As I said, "int" stands for "internal".
If there are things that callers of libpcap would use, they should be
put in "pcap.h".
> so that some of us can get the most out of libpcap, put in some
> version numbers, so that we can find out what version of
> libpcap we're talking to,
Well, there is the (undocumented) "pcap_version[]" array, which contains
a version number string. However:
on UNIX systems, it would often be the version with which the
program was built, due to the way data in libraries is handled
in many UNIX shared library mechanisms, not the version being
used (the two may be different if libpcap is
dynamically-linked);
it's not available on all platforms.
A routine to return the version number of the library currently being
used, as a string, would be useful (the version numbers would probably
be small enough that they would be immediate data in instructions, so
that they wouldn't get stuck in the data segment and linked in at build
time even with dynamic shared libraries; the string could then be
generated using "snprintf()").
> and try to keep the internal structures stable when possible.
If there are accessor routines to get the relevant information, the
internal structures don't need to be stable.
> Removing readlen from
> struct pcap_md, does not seem to me to be in the same
> spirit as removing pcap-int.h from the distribution.
"pcap-int.h" is, obviously, part of the source code distribution, and
has been part of the source code distribution for as long as it's
existed, so it was never removed from the distribution.
It is, however, not *installed* as a header file for the use of programs
*using* libpcap - and, as far as I know, never was! libpcap 0.4
installed "pcap.h" and "pcap-namedb.h", but not "pcap-int.h"; we
continue not to install it, as it's not supposed to be installed.
Perhaps they install it on some platforms, but it's not installed on all
platforms and, as indicated, it shouldn't be (exported stuff belongs in
"pcap.h"; the whole reason for "pcap-int.h"s existence is to hold the
stuff that's *not* exported).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
