Are you sure you are evaluating your binary
'00000000' properly as you claim? Send a sample code
alrightey then. the binary data itself is actually stored in a mysql
table. (mysql 5.1.9) the relevant part is the following column:
+------------+-----------------
| Field | Type
+------------+-----------------
| bit_string | bit(8)
+------------+-----------------
but of course there are others. assuming there weren't however, data
would be inserted into this table with a queries similar to:
INSERT INTO blah SET bit_string=b'00000001';
INSERT INTO blah SET bit_string=b'00000011';
INSERT INTO blah SET bit_string=b'00000100';
this part appears to work great. i just discovered the bit type in
mysql myself and have been having great fun with it. just in case you
hadn't heard of it reference here: (*please* don't be insulted if this
is old news to you)
http://dev.mysql.com/doc/refman/5.1/en/bit-field-values.html
anyway, when this data is selected from the table the characters are
clearly being represented correctly, they show up unprintable in various
wierd ways and return correct values for bitwise operations. the
problem happens when you try to say:
<?php
// assume this code is part of a method of a greater class that has a
member database handle already initialized...
--- snip ---
$bit_strings = array();
$rh = $this->_dbh->query('SELECT bit_string FROM blah');
if($rh !== false && $rh->num_rows) {
while($bit_string = $rh->fetch_assoc()) {
$bit_strings[] = $bit_string;
}
$rh->free();
}
return $bit_strings;
--- snip ---
// ok so lets say you call this method and just for simplicity sake (no
its really not anywhere near this simple) *know* that the three values
above are the only things that get returned. lets say we know that we
will have an array of three values, which are the binary 1, binary 3,
and binary 4, we inserted above, in that order. in that case the
following check:
if($bit_strings[0] & $bit_strings[1]) {
// blah
}
//evaluates to a binary 1 and is therefore true, as would be expected,
but this check:
if($bit_strings[0] & $bit_strings[2]) {
// blah
}
// evaluates to a binary zero but STILL counts as true! (go ahead, try
it yourself)
?>
Now two things are worth stating here. First is that its comforting to
see unpack('C',... in your sample code, because my fix for the problem
last night eventually turned out to be:
$bits = array_pop(unpack('C', ($bit_string_one & $bit_string_two)));
settype($bits, 'integer');
if($bits) {
return true;
}
... and though it seemed to work the way i wanted i was previously
unfamiliar with unpack/pack and was worried i was approaching this
entirely in the wrong way. Thank you for that.
The second thing that needs to be said here is simply a re-statement of
the original, this time more verbosely. The list of things in php that
evaluate as false is as follows:
* the boolean FALSE itself
* the integer 0 (zero)
* the float 0.0 (zero)
* the empty string, and the string "0"
* an array with zero elements
* an object with zero member variables (PHP 4 only)
* the special type NULL (including unset variables)
* SimpleXML objects created from empty tags
now, all i'm saying is that if, of all ungodly things, the literal
string "0" and empty arrays evaluate to false, isn't it appropriate to
expect a binary zero to evaluate to false as well? Maybe i still don't
get it. :(
thanks btw, for your time.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
