RFC added. I'm not sure what the protocol for RFCs is, but I put it under
the In Discussion heading. Sorry if I was wrong.
http://wiki.php.net/rfc/binnotation4ints
Just one little note: If I'm not mistaken this would introduce a subtle BC break when doing the comparison "0b1" == 1 which is false now but would return true afterwards, right? Likewise is_numeric("0b1") would suddenly return true.
Is it worth the (possible) WTF for something hardly ever used?
- Chris
RFC added. I'm not sure what the protocol for RFCs is, but I put it under
the In Discussion heading. Sorry if I was wrong.
http://wiki.php.net/rfc/binnotation4intsJust one little note: If I'm not mistaken this would introduce a subtle BC break when doing the comparison "0b1" == 1 which is false now but would return true afterwards, right? Likewise is_numeric("0b1") would suddenly return true.
Is it worth the (possible) WTF for something hardly ever used?
- Chris
var_dump(is_numeric("1"));
var_dump("1" == 1);
var_dump("1" === 1);
var_dump(is_numeric("0x1"));
var_dump("0x1" == 1);
var_dump("0x1" === 1);
var_dump(is_numeric("0b1"));
var_dump("0b1" == 1);
var_dump("0b1" === 1);
bool(true)
bool(true)
bool(false)
bool(true)
bool(true)
bool(false)
bool(false)
bool(false)
bool(false)
Probably would be the same as "0x1".
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
Just one little note: If I'm not mistaken this would introduce a subtle BC
break when doing the comparison "0b1" == 1 which is false > > now but
would return true afterwards, right? Likewise is_numeric("0b1") would
suddenly return true.Is it worth the (possible) WTF for something hardly ever used?
- Chris
With regards to parsing numeric strings, only decimal is supported, and in
some cases (unfortunately) hexadecimal, like your comparing example. But
octal is not supported in strings, and neither should binary.
0xF == 15 // true
'0xF' == 15 // true
010 == 8 // true
'010' == 8 // false
It should be a important consideration that numeric string parsing isn't
affected by this patch, and things will be fine.
In fact it should be a separate discussion whether hex should work in
strings at all. It's very counterproductive when parsing user input.
Stan Vass
Am 12.11.2010 um 09:22 schrieb Stan Vass:
With regards to parsing numeric strings, only decimal is supported, and in some cases (unfortunately) hexadecimal, like your comparing example. But octal is not supported in strings, and neither should binary.
0xF == 15 // true
'0xF' == 15 // true
010 == 8 // true
'010' == 8 // false
You're right. (Side-note: '010' == 10 // true, i.e. is is parsed as a decimal number)
It should be a important consideration that numeric string parsing isn't affected by this patch, and things will be fine.
If neither '0b1' == 1 nor is_numeric('0b1') is true after this patch then I see no problem.
Sorry for not trying the patch first and assuming that it would be similar to the other formats.
In fact it should be a separate discussion whether hex should work in strings at all. It's very counterproductive when parsing user input.
While you might be right this cannot be changed now as it would break compatibility without big benefit.
- Chris
On Fri, Nov 12, 2010 at 5:49 AM, Christian Schneider
cschneid@cschneid.comwrote:
It should be a important consideration that numeric string parsing isn't
affected by this patch, and things will be fine.If neither '0b1' == 1 nor is_numeric('0b1') is true after this patch then I
see no problem.
This is correct--both evaluate to false. String parsing support for binary
literals was not added.
Sorry for not trying the patch first and assuming that it would be similar
to the other formats.
No worries.
--
Jonah H. Harris
Blog: http://www.oracle-internals.com/