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