On Tue, Sep 11, 2001 at 12:31:52PM +0200, Karol Konrad Kisielewski wrote:
> While I was playing with libpcap-0.6.2 library, I noticed than when errbuf
> function argument is set to NULL (for example in pcap_lookupdev), the
> compiled program return
> "segmentation fault". I know that errbuf must be set to char string to
> avoid it, but it isn't nice when some absent-minded programmer
> forget about it and see "segmentation fault" message.
No, it's not nice when some programmer forgets about it - but the reason
why it's not nice is that they're not supposed to forget about it, and
the segmentation fault reminds them.
The only time when it would make sense not to pass a pointer to a
message buffer as an argument to libpcap routines would be times when
the program is calling that routine and, if the routine fails, not
reporting the error at all.
There are times when this is the right thing to do - I'm even the author
of some code that does that (Ethereal checks, before adding a network
device to the combo box for the interface on which to capture, whether
the interface can be opened with "pcap_open_live()", as that's the only
way to deal with, for example, loopback interfaces - not listing them at
all is an error, as you can capture on loopback interfaces on Linux, the
BSDs, and Digital UNIX, but always listing them is also an error, as you
can't capture on them on Solaris).
However, I'm not sure that there are enough such times that it's worth
adding checks to a number of libpcap routines, rather than supplying a
buffer which is filled in but not used, and I'd also prefer to make it
harder for somebody to report an error message that doesn't include the
error string returned by libpcap (as doing so means that some
information may be lost, making it harder to figure out *why* the error
is occurring).
-
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
