On Nov 20, 2008 at 18:02, Henning Westerholt henning.westerholt@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