Re: Initializing a device

[Guy Harris <guy () alum mit edu>]

On Jan 6, 2012, at 2:16 PM, Akos Vandra wrote:

> On 6 January 2012 17:16, Jakub Zawadzki <darkjames-ws () darkjames pl> wrote:
>
> > Let's have just:
> >  int pcap_setparam(pcap_t *p, const char *param, const char *value)
> >
> > If param is not understand, or value is invalid for given param (like: not integer)
> > it should return -1.
>
> Yeah, this would simplify the API.
> The other side to this argument is that if the application wants to
> set some calculated value, then it needs to put that into a string,
> call this function, which will parse it back to an integer. It's not
> efficient, but I don't really think this is a problem as we don't do
> it often - only when opening a device, or at least with our current
> model. And even if later this would be used for an already live pcap
> handler, I doubt it would be called too often.
>
> Maybe even the _uint, _bool, _int64, etc. calls could be only wraps
> around this one to simplify things in some cases.

Once you've done that, whether they're wrappers or not is just an implementation detail; pcap_setparam() would be 
something you use for user text input (command-line and text-widget), and the other pcap_setparam_XXX() calls would be 
used for:

        user non-text input (checkboxes that would return a Boolean, spinboxes that would return a number, combo 
boxes/option menus that would return an enum value, etc.), as having to convert from those input values to text would 
be an extra burden;

        calculated input where you'd again need to convert to text (for constant input you could use a constant string).

My concern is less with the CPU efficiency than with the programmer efficiency - I'd rather not have to have to use 
asprintf() or whatever.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.