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

[Andrei Pelinescu-Onciul]

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.


Andrei