check_cidr() in resources/functions.php doesn't handle 0.0.0.0/0 properly on 32 bit

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Call check_cidr() with 0.0.0.0/0 on a 32 bit system

Simple example script which can be placed in the main FusionPBX directory:

<?php
require_once('resources/functions.php');
print(check_cidr('0.0.0.0/0', '192.168.1.1'));
print(check_cidr('128.0.0.0/1', '192.168.1.1'))
?>

What is the expected output? What do you see instead?

Expected output should be the number 1 being printed twice, once each for lines 
2 and 3.  On 64 bit this works as expected, on 32 bit it does not and only line 
3 results in a 1 being printed.

What version of the product are you using? On what operating system?

Failure initially found on 3.6.3, but the function is 100% identical in current 
SVN dev branch.  Operating system where it works as expected is Ubuntu 12.04 
AMD64, operating system where it doesn't work is CentOS 6 i686.

Please provide any additional information below.

Given that this function is doing bitwise operations on a 32 bit number, I'm 
guessing that some kind of 32 bit PHP platform limitation is coming in to play 
here.  Still fiddling around to see what the specific cause is.

Original issue reported on code.google.com by s...@seanharlow.info on 26 Apr 2015 at 1:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Working with "reliberate" on IRC we did find that using a workaround of 
0.0.0.0/1 + 128.0.0.0/1 has the same effect as 0.0.0.0/0 while still working on 
32 bit.

As far as I can tell this function is only used in two areas, provisioning and 
somewhere in pdo.php that seems to be API related.  I can't tell how well this 
workaround works for the other part, but it seems to work great for 
provisioning.

Original comment by s...@seanharlow.info on 26 Apr 2015 at 1:55

[GoogleCodeExporter]

The cidr function works on 64 bit and fails on 32 bit. So don't use the cidr 
function on 32 bit at this time. To not use cidr don't define a value for it.

Original comment by markjcrane@gmail.com on 28 Apr 2015 at 3:50

[GoogleCodeExporter]

[deleted comment]