Hello,
On 11/25/13 1:51 PM, Hugh Waite wrote:
Hello,
We are having an issue with PVs after upgrading to the latest master
(i.e. 4.1.0-pre1) which might be related to the comparison of $null and 0
In our previous version (compiled on 9th October) the following code
worked. It is using the htable as a DB cache
$var(ip_trusted) = $sht(trusted=>$var(srcip));
if($var(ip_trusted) == $null) {
/* DB lookup */
$sht(trusted->$var(srcip)) = $var(ip_trusted);
}
After upgrading, the first line is not working as expected. The htable
value is null (not assigned), but the $var(ip_trusted) value is
assigned the value 0, so the check fails.
Is this related to the pv comparison bugfix
(
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=38…
Certainly something has changed since 9 Oct.
It is related to that change, fixing
an old issue.
The 'null' variable was designed to undefine variables or test if a
variable is undefined.
An undefined variable is the one that doesn't exits. Like $avp(x) might
not be in set at all. Some variables always exists, because they are
always declared and initialized to 0 if not other default source of
value, such variable is $var(x).
So practically a $var(x) cannot be 'null' at any time.
Probably with the ser-kamailio integration, the comparison with 'null'
(which became to be refered as $null) got the inconsistency bug of
actually comparing with 0 instead of returning whether the variable
exists or not.
So, for the case:
$avp(x) = 0;
the condition if($avp(x)==$null) was true, while it should have been
false because $avp(x) is defined, not offering the true result when
there was not $avp(x).
In other words, $null should be compared with variables that could be in
the situation of an non-exiting value.
For your example, $var(ip_trusted) should be compared with 0, or you can
compare the $sht(trusted=>$var(srcip)) with $null.
Cheers,
Daniel
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda