[SR-Users] Inconsistent string interpolation

[Sven Neuhaus]

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.

>>> 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.

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.

>>> - 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.

Cheers,
-Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151002/0ae3537a/attachment.sig>