Edit report at https://bugs.php.net/bug.php?id=61220&edit=1
ID: 61220
User updated by: dosergio at ig dot com dot br
Reported by: dosergio at ig dot com dot br
Summary: is_numeric returns FALSE for chr(0) and CHR(1) that
are BIT, so NUMERIC.
Status: Not a bug
Type: Bug
Package: *General Issues
Operating System: ALL
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you. You made me see that the problem is really with MySQL, not PHP.
I thought PHP x MySQL were totally compatible, but as we see, the bit data type
is only bit for MySql, PHP sees it as non numeric string.
I imagined php could validate only chr(0) and chr(1) as valid numeric string
exactly to make php even more glued with MySQL.
You are right about the binary context, and I suggested to have a special
treatment only if the char was chr(0) and chr(1) not any others out of 48~57.
Previous Comments:
------------------------------------------------------------------------
[2012-03-01 18:34:32] anon at anon dot anon
@dosergio
Chr is a PHP function that returns a string with the specified character code.
Try this:
var_dump(chr(0));
It says:
string(1) " "
It's a string, and not a string containing a human-readable number, so
is_numeric returns false as it says it will do in the documentation.
>numeric in the binary context
Everything is numeric in the "binary context". If is_numeric returned true for
that reason, then it should be hard-wired to return true always, because you
cannot possibly pass it an argument which is not made of bits.
>Tell the MySQL team that they are wrong, because they are storing chr(0) and
>chr(1) for bit(1) values.
I won't say that they're wrong, but they're definitely different to all other
databases in this way. Read:
http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/
For some reason, new versions of MySQL return BIT columns to clients as strings
instead of integers. To avoid the problems this causes, you could do one of the
following:
(a) use an integer column instead (e.g., TINYINT(1) instead of a BIT(1))
(b) put +0 in the SQL expression, which forces the bit value to be returned as
a number
(c) use the PHP ord() function to convert the character into its character code.
In any case, it's not a PHP bug.
------------------------------------------------------------------------
[2012-03-01 18:22:27] ras...@php.net
Yes, binary is 0's and 1's at the low level. So is octal, decimal and
hexadecimal
or anything else you represent digitally. What matters here is the character
representation of these numbers. The character representation of binary (as of
PHP 5.4) is 0b0101 (for example). Just like 05 is octal, 5 is decimal and 0x05
is
hexadecimal. All of these make is_numeric() return true.
------------------------------------------------------------------------
[2012-03-01 16:26:11] dosergio at ig dot com dot br
Do you know the binary numeric system ?
Chr(0) is the octet 00000000 which value is 0, so it's NOT different from zero.
Chr(1) is the octet 00000001 which value is 1, NOT different from the numeric 1.
These two chars should ALSO be recognized as boolean in the "is_bool" function
too. Everybody that program in C knows that 0 and 1 are the real booleans
inside the engine.
If you are so sure, take the chance, and tell the MySQL team that they are
wrong, because they are storing chr(0) and chr(1) for bit(1) values.
Bit is defined as numeric data type in MySQL
------------------------------------------------------------------------
[2012-03-01 15:45:58] ras...@php.net
No, definitely not. chr(0) is a NUL which is distinct from the number 0 and
chr(1) is a SOH character which has absolutely nothing to do with a number.
------------------------------------------------------------------------
[2012-03-01 15:02:02] dosergio at ig dot com dot br
I also tested chr(0) and chr(1) with is_boolean and of course the function says
it is not.
I think is_numeric and is_boolean should be revised to include 0, 1, chr(0) and
chr(1) as valid numeric and valid booleans.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61220
--
Edit this bug report at https://bugs.php.net/bug.php?id=61220&edit=1
