[SR-Dev] git:sip-router: mod if: more prototypes and defines

Daniel-Constantin Mierla miconda at gmail.com
Thu Nov 20 18:59:02 CET 2008


On 11/20/08 19:43, Andrei Pelinescu-Onciul wrote:
> On Nov 20, 2008 at 18:02, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
>   
>> On Thursday 20 November 2008, Andrei Pelinescu-Onciul wrote:
>>     
>>> [..]
>>> Example for a variable number of parameters function:
>>>
>>> static cmd_export_t cmds[]={
>>>     {"print", print_f_0, 0, 0, REQUEST_ROUTE},   // overload test
>>>     {"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
>>>     {"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
>>>     {"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0,  REQUEST_ROUTE},
>>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>     {0, 0, 0, 0, 0}
>>> };
>>>       
>> Hi Andrei,
>>
>> thank you for providing this. I found working with a bunch of function 
>> parametern is much more natural then providing different "avp_foo" variables 
>> that are used in other modules as a workaround. Where one should check for a 
>> valid number of parameters  when this VAR_PARAM_NO is used? In the fixup 
>> function, or the function implementation?
>>     
>
> In the implementation is easier.
>
> In the fixup is possible, but would require using something like:
>  action_u_t* pno = (char*)param - &(((action_u_t*)0)->u.string) -
>                    (param_no+1)*siezof(action_u_t);
> parameter_no=pno->u.number.
>
> (for static int print_fixup_f_2(void **param, int param_no)).
>
> Another nicer way to do it is: 
>
> pno=fixup_get_param(param, param_no, -1);
> parameter_no=pno->u.number;
>
> (all this takes into accounts that the fixup functions get a pointer
>  to an action_u_t u.string member and that before the parameters
>  the number of parameters is stored, slightly different than kamailio)
>
> We could make a macro for it to hide the ugliness and param. arrays
> implementation details.
>   
as we got into this discussion, for the future, it may make sense to 
call the fixup with the array of the parameters and the number of 
parameters - the fixup will iterate through parameters. Some times, 
depending on the number of parameters, the meaning can change, or based 
on the values of couple of the parameters we can do some optimizations. 
Now calling the fixup for each parameter is a bit inconvenient from this 
perspective, IMHO.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com




More information about the sr-dev mailing list