I vote fore keeping the support for "if (@to.tag)" like expressions, and adding the extra functions for more precise checks if necessary. So a string value could evaluate to true if it exists and not "".

I think it is easier to read and understand "if (@to.tag)" then "if (!strempty((a)to.tag))"

Both of them would return false. Btw, I do not think that empty value is allowed for to tag, it's a very rare case, and could be covered with some explicit check.

We used to write this, but had lots of issues. The problem happens for example with @contact.uri.user, when there is no contact header. Unfortunately the select function can return and error instead of success with "" value in this case. (The can be also revisited) And 'if (@contact.uri.user == "")' would evaluate to false because the left had side value does not exist, which is wrong.

Hi, On 04/24/2009 06:44 PM, Juha Heinanen wrote: Yes, this could work, but than we need two checks in most of the cases: if (defined($v) && ($v != "")) {...} This is more precise indeed, but the script writer should not forget the extra checks.

Regarding SER selects, if we go for this solution, I think we should revisit all the select functions. For example @foo.param.abcd should return "" only if the 'abcd' parameter of header 'foo' exists, but it's value is empty. Than we could simply check the existence of the parameter: if (defined((a)foo.param.abcd)) {...}

Andrei Pelinescu-Onciul writes: yes, in case there are some. if $foo is undefined, it is insane to me that it would be equal to empty string "" or 0. also comparing two undefined things should not result in true.

what would make sense to me is that comparing an undefined thing to anything that is defined, would result in false.

again "" == 0 makes no sense. -- juha

On Apr 28, 2009 at 09:53, Miklos Tirpak <miklos(a)iptel.org> wrote: Actually if you think in terms of the operators it's not. The operators forces conversion of its operands to the type it expects. so for eq (which used for string): $foo eq undef is in fact (str) $foo eq (str) undef , and (str) undef is "". With undefined you have 2 options: either have valid conversion to string and ints or bail out with an error. Since we cannot stop the script or abort(), even if we report an error we still have to come up with a result. Bear in mind, that == in this case (perl) is an int operator, so "abcd" == undef is in fact (int) "abcd" == (int) undef and (int) "abcd" is 0 (int) undef is 0 => 0 == 0.

I don't. We have special operators for checking if something is defined or not. If you don't use it you want implicit conversion. In almost all script languages, if a var is undefined then it's equal to "".

If you think some other behaviour is better, please fill all the table and think also about normal operations, e.g. $v int+ $x, $v str+ $x. Bear also in mind that we support 2 types: int and str. We don't support bool (bool is int) so all logical expressions are evaluated to int (so you cannot say bool("a") == true but int("a")==0). Also think about how other scripting languages handle that.

Andrei

On Apr 28, 2009 at 13:09, Miklos Tirpak <miklos(a)iptel.org> wrote: For now we could keep it, but for next releases we need some changes. We need at least different version for ==, != and + for integer and strings. Overloading them to work for both is just broken and it will lead to strange behaviour. Another important change would be typed variables and avps (we would be able to do much better error checking on the script and make life much more easier for script writers at the cost of only having to pre-declare the vars with the intended use type). I've introduced eq, ne for strings, ieq and ine for integers. The names are temporary as their intended use is testing (for possible introduction in the next-next release). This is ok, this is the way it behaves now (on my type_conversion branch). ^^^^^ this is not, but it's related to the string to int conversion (below) ^^^^^ we do not have boolean and I don't think introducing it would be a good ideea. ^^^^^^^^^^^^^^^^ right now in my branch it works like this: at startup you'll get an error (if the type is known to be string). If the type is not known (avp pvar) => I can't tell if it's an error or not, At runtime it's 0 (for "", "abc") or I (for "123"). No error is generated (it wouldn't help anyway, it's too late). That's what I want to avoid, different behaviour. I've attached a first draft describing how type conversion and operators work in sip-router. It describes the code on the andrei/type_conversion branch. If I won't get strong objections, I'll merge that branch into master (we can't waste too much time arguing, we need to have something sane and something that mimics perl behaviour as much as possible it should be at least good enough). If people are worried about specific ser or kamailio script snippets that won't work, then please provide some _simple_ test config that I can use. By simple, I mean something using very few modules (only xlog & pv would be ideal) and having something like: $var=expr_that_might_not_work; if ($var != expected_value ) xlog("L_CRIT", "BUG: sanity check 1 failed"); if ( expr2 != expectred_value) xlog("L_CRIT", "BUG: sanity check 2 failed"); a.s.o. We could collect them and use them for testing each time we do a change to expression evaluation. Andrei _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

i would prefer to have no automatic conversion of int to string or string to int or conversion of undefined variable to anything. it would be enough if there exist conversion functions int() and str() like in python. this would also greatly simplify the implementation.

On Friday 24 April 2009, Andrei Pelinescu-Onciul wrote: Hi Andrei, does this also apply to kamailio pseudo-variables that evaluates to a string, like this: if ($hdr(X-Foobar)) { # do something on this hdr } If yes, then i'd vote for keeping this functionality, as its more easier to read and understand as using another operator, as Miklos already said.