Re: Initializing a device

[Akos Vandra <axos88 () gmail com>]

We could put a limit - say 32 or 64 chars - to the max length of the
param, and then allocate in on the stack, but it would still require
printf.
In this form, as we are going to have a single interface function to
set and read the parameter, some serialization and deserialization of
the data is necessary... Either that, or the interface has to be
changed to somehow accomodate multiple type input parameters...
Varargs maybe?

Regards,
  Ákos

On 11 January 2012 10:24, Guy Harris <guy () alum mit edu> wrote:
> 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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.