On 02/10/15 11:00, Sven Neuhaus wrote:
> Am 02.10.2015 um 08:38 schrieb Daniel-Constantin Mierla:
>> On 01/10/15 14:34, Sven Neuhaus wrote:
>>> Am 01.10.2015 um 12:53 schrieb Daniel-Constantin Mierla:
>>>> For assignments, that is the general interpreter which considers strings
>>>> as being the tokens in between quotes. Trying to interpret variables
>>>> inside the strings automatically won't work, because that will mean to
>>>> do it for cases when it should not happen (e.g., modparams or function
>>>> parameters that specify just name of variables).
> In those cases there should be a different syntax, such as single quoted
> strings or escaping the $ sign with a backslash or - if you prefer it
> the "C" way, the & "address of" operator - to make it clear a reference
> to a variable is passed and not its content.
>
>>>> Of course, with some
>>>> extra coding to keep states of where that string is used might be
>>>> possible, but I think will make the interpreter too complex. I might be
>>>> wrong, so a patch is welcome to prove the otherwise :-)
>>> Ideally, all variables in double quoted strings should be interpolated
>>> and single quoted strings should not (the same way it is done in bash,
>>> Perl, PHP, Groove, Ruby and elsewhere).
>> In C is not :-) .
> But then again, in C the string interpolation is consistent.
> Removing it altogether and making $_() mandatory for string
> interpolation would avoid confusion.
What I wanted to say is that in C is up to me to interpret as function
developer, for example:
int i = 0;
void myprint(char *v) {
if(strcpy(v, "i")==0) {
printf("%d", i);
} else {
# error - unknown global variable
}
}
or:
void myprint(char *v) {
printf("%s", v);
}
Then use:
myprint("i");
Now, would you like the ccompiler to expand i inside the parameter?
All PVs in kamailio are global variables. Now it is up to myprint()
developer to do what he needs with that parameter.
>
>>>> Some functions can evaluate the parameter content, some don't. And in
>>>> some cases, even there is a variable inside a parameter for a function,
>>>> it is not evaluated, but it is set. That's again based on the purpose of
>>>> the function.
>>> That's frightening!
>> Why? Do you know the purpose of parameters for C libc functions without
>> fist looking at the manual? One needs to retrieve values, so instead of
>> evaluating the value, is about setting the value.
> For starters, it would need to be in the documentation of every
> function, which it is not currently.
All functions for modules are documented in the readme of the module, if
you find one which is not, then it is considered a bug and should be
fixed quickly. You can see all those functions indexed by name at:
http://www.kamailio.org/wiki/alphaindexes/4.3.x/modfunctions
>
> It's one thing to know what a function does and what its parameters are.
> It adds a whole level of complexity and source of errors having to look
> up which one of those parameters will be interpolated. That's why noone
> else is doing it that way.
Well, in C a parameter can be pointer and can be used for input (read)
of output (write).
The & (reference) and * (pointer) operators in C are not for saying it
is a parameter for write or read. Practically behind each PV is a
pointer in the C code, because we cannot any longer declare a
non-pointer variable from kamailio.cfg back to c code (which is already
compiled at the time kamailio.cfg is loaded).
>
>>>> - pv_printf($var(x), ...)
>>> I looked up the documentation for pv_printf() in the KEx module and was
>>> baffled to see the variable name being passed as a string in the example
>>> ... "pv_printf("$ru", "sip:$rU@$fd");" :-*
>> That's pretty much from day 0 of sip express router back in 2001 -- the
>> parameters of functions from modules had to be enclosed in double
>> quotes, not matter what they are. There was no support for expressions
>> as parameters for functions. Later there were some changes and some
>> parameters can be without double quotes, but that is not the general
>> rule -- if in double quotes, it should work always (for module functions).
> Again, here we have the situation that there is a parameter to a
> function call where the first parameter is not interpolated and the
> second one is. That is not a good idea!
>
> By the way: With the modparam() function the behaviour differs depending
> on the module that is being configured.
>
> I think it would make Kamailio easier and less error prone to configure
> if the string interpolation behaviour were identical in all places.
>
I am open to discuss and even help evolving the interpreter to be more
friendly. But for this specific case I don't really see your point.
And documentation for all those functions is there, prove a missing one
and will be fixed as said above. Even if there would be '&' or '*', you
have to read the docs to see what that function does, how many
parameters and what those parameters should be.
Start a wiki page on kamailio.org/wiki/ in the development section
collecting what you would like to have, then email to sr-dev to get
input from other developers interested in the topic.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training - http://asipto.com/u/kat
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
