On 11/20/08 19:43, Andrei Pelinescu-Onciul wrote:
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.
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