Re: [PATCH] enable memory mapped access to ethernet

["Gianluca Varenni" <gianluca.varenni () cacetech com>]

----- Original Message ----- 
From: "Alexander Dupuy" <alex.dupuy () mac com>
To: "tcpdump-workers" <tcpdump-workers () lists tcpdump org>
Sent: Wednesday, December 12, 2007 7:52 AM
Subject: Re: [tcpdump-workers] [PATCH] enable memory mapped access to 
ethernet


> Gianluca Varenni wrote:
> > Having a function that
> > returns success but then spits out a human only readable warning string 
> > in a
> > parameter called "errbuf" and not "warnbuf" (also considering that 
> > there's
> > an errbuf in the pcap_t structure that can be retrieved with 
> > pcap_geterror()
> > or similar) is not that elegant IMHO.
>
> I agree.  And basically echo Guy's comments about how other functions that 
> return errors work.
>
> I'll note that if pcap_setbufsize returns an error (-1 return) the 
> contents of errbuf are in fact an error message and not a warning 
> message - it's only if there is a non-empty string in errbuf on success (0 
> return) that this is a "warning."  And, this is the same string that you 
> would get from a call to pcap_geterror, but it's more convenient to get 
> the value directly than to make a second call.

Ok, so basically we want to adhere to the model of other pcap functions, 
that return success/failure and in case of failure calling pcap_geterror 
returns the error string.  *But* in this case the error string is returned 
directly from the function (the same string you can get from pcap_geterror). 
You say "because it's more convenient". It would be more convenient if all 
the other pcap_ functions did the same. Not just one (and having to call one 
function instead of two for me it's convenience). And if there is a warning, 
the function returns success, and the *warning* message is returned in a 
parameter called "errbuf".

This discussion started with a simple request from someone to add a new 
function to set the kernel buffer size, so... ok...

Have a nice day
GV

> Not the most elegant, I agree, but it's just what I did in our private 
> version of libpcap.
>
> @alex
>
> --
> mailto:alex.dupuy () mac com
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe. 

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.