Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

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  wrote:
>
> On Jan 6, 2012, at 2:16 PM, Akos Vandra wrote:
>
>> On 6 January 2012 17:16, Jakub Zawadzki  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.

Re: [tcpdump-workers] Initializing a device

[Guy Harris]

On Jan 12, 2012, at 1:06 AM, Akos Vandra wrote:

> 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.

Where would that be done?  It's a little more convenient than using routines 
such as asprintf() and g_sprintf(), because you don't have to free the result, 
but it's still extra work.

> In this form, as we are going to have a single interface function to
> set and read the parameter,

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

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

On 12 January 2012 10:38, Guy Harris  wrote:
>
> On Jan 12, 2012, at 1:06 AM, Akos Vandra wrote:
>
>> 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.
>
> Where would that be done?  It's a little more convenient than using routines 
> such as asprintf() and g_sprintf(), because you don't have to free the 
> result, but it's still extra work.

In the wrapper functions (setparam_xxx)
for ex something like this:

int setparam_uint64(pcap_t * pcap, char* param, uint64_t value)
{
  char[64] buf;
  sprintf(buf, "%lu", value);
  return pcap->setparam_op(param, buf);  //Add check for NULL op
}

>
>> In this form, as we are going to have a single interface function to
>> set and read the parameter,
>
> Which form is that?

That we use only one function ptr to set and get parameter values,
which uses char* as parameters.

> -
> 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.