Am 02.10.2015 um 11:51 schrieb Daniel-Constantin Mierla: > 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: >>>> 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.
There is no way (that I know of) to access a variable by its name in C, i.e. converting a string that contains a variable name back into a reference to the actual variable. Your example has a hard-coded variable name "i" to make it work. There are some script languages that will allow you to get access to a variable if you only know its name (some do it with tricks such as eval() or reflection in Java). I consider passing a reference to a variable by using a string with its name to be ambiguous and error-prone. >>>>> 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 >>> first 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 The functions are documented of course, however it isn't clearly stated how its strings are interpreted. Sometimes it can be guessed but it's open to interpretation. A random example is the function ds_list_exist(groupid) from the dispatcher module. If I pass a variable in a string to this function, will it retrieve the value of the variable or will it try to interpret the variable name as a groupid? I have no idea. If I pass a variable without quotes, I hope it will get interpolated. >> 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 no-one >> 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). I'm not sure I fully understand what you are getting at here. >>>>> - 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. There's $sht() that explicitly states that the key can be static or dynamic. What happens if the string contains something like $xyz and there is no such variable? Will it then use the string verbatim? That doesn't seem like a good idea. > 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. OK I'll try to think this through once I am finished with the current project at work. Have a nice weekend! -Sven
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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