#12435 [Fbk->NoF]: Incorrect results from logical AND

ID: 12435 Updated by: php-bugs@lists.php.net Reported By: lovan@lifesci.ucsb.edu -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Solaris 2.8 PHP Version: 4.0.5 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: ------------------------------------------------------------------------ [2002-08-13 22:45:20] iliaa@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP has already 2 built in functions to do what you need, long2ip and ip2long. You should use those functions when converting IPs to integers and vice versa. When dealing with integers that can go above 2 billion, on 32 bit systems, make sure you do sprintf("%u") on the result/variable, which will make PHP treat it as an unsigned number. ------------------------------------------------------------------------ [2001-07-27 14:23:12] lovan@lifesci.ucsb.edu I'm using an integer to store an IP address as a 32-bit value rather than a dotted-quad string and get odd results. Since I'm only using it for shifting bits, I don't think it should matter that PHP is missing an unsigned integer type. $foo = (255 << 24) | (111 << 16) | (241 << 8) | 254; $octet[0] = ($foo & 0xff000000) >> 24; $octet[1] = ($foo & 0x00ff0000) >> 16; $octet[2] = ($foo & 0x0000ff00) >> 8; $octet[3] = ($foo & 0x000000ff); $quad = "$octet[0].$octet[1].$octet[2].$octet[3]"; The expected end result is that I get a dotted-quad string ($quad) that is the same as was used to build $foo. Instead, $octet[0] is miscalculated; it appears as "0" instead of 255. I've tried it for a variety of values and keep getting the same kind of erroneous result. However, if I change the statement to: $octet[0] = (($foo >> 8) & 0x00ff0000) >> 16; I get the expected result. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=12435&edit=1