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

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