Bug #66399 [Asn->Fbk]: Inconsistent runtime support for integer binary/hex syntax
| From: | dmitry@php.net | Date: | Thu, 09 Jan 2014 06:37:24 +0000 |
| Subject: | Bug #66399 [Asn->Fbk]: Inconsistent runtime support for integer binary/hex syntax | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-183659@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=66399&edit=1
ID: 66399
Updated by: dmitry@php.net
Reported by: benjamin at zikarsky dot de
Summary: Inconsistent runtime support for integer binary/hex
syntax
-Status: Assigned
+Status: Feedback
Type: Bug
Package: Strings related
PHP Version: 5.5.7
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
I would agree to remove hex numbers support in is_numeric_string() (in PHP-5.6), but it really may
break some code.
Previous Comments:
------------------------------------------------------------------------
[2014-01-04 08:06:40] krakjoe@php.net
This was the non-obvious thing that didn't cross my mind:
(Try to explain to an end-user how 0123 and 123 are totally different things...)
It doesn't really make a lot of sense to me to support anything at compile time that cannot be
supported at runtime, if the compiler understands something then so should the executor.
If we cannot support it then they should all be removed, maybe introducing utility functions to work
with these forms, instead of trying to half bake it into the engine.
I'd prefer to just remove them if they cannot be supported sanely, there isn't really
another good option.
------------------------------------------------------------------------
[2014-01-04 00:44:59] yohgaki@php.net
Added this issue to RFC to track.
https://wiki.php.net/rfc/comparison_inconsistency
------------------------------------------------------------------------
[2014-01-03 20:14:14] nikic@php.net
Consensus is that hex support in is_numeric_string should be removed (see e.g. http://markmail.org/message/ax2drcb6dolr5agl).
Doing it the other way around would be a major PITA, as we'd have to support not only binary,
but also octal and would have to add support for it in typecasts as well. (Try to explain to an
end-user how 0123 and 123 are totally different things...)
But we can't remove this just now, will have to wait to next major.
------------------------------------------------------------------------
[2014-01-03 18:19:11] requinix@php.net
The one particular thing I'd be worried about is someone using is_numeric() to check that a
string is a number (eg, form input) and then inserting that into a SQL query: if a user entered
0b100 that now looks numeric but MySQL, for one, doesn't support it and the query would fail.
(Meanwhile hex looks numeric already but MySQL supports it.)
The other methods - int cast, *val() - are fine because they return a new value rather than return
just information (numeric-ness) about the value.
However fixing all but is_numeric() would be even more horribly inconsistent...
------------------------------------------------------------------------
[2014-01-03 14:25:36] krakjoe@php.net
The following patch has been added/updated:
Patch Name: inconsistent-bin-hex-handling.patch
Revision: 1388759136
URL: https://bugs.php.net/patch-display.php?bug=66399&patch=inconsistent-bin-hex-handling.patch&revision=1388759136
------------------------------------------------------------------------
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=66399
--
Edit this bug report at https://bugs.php.net/bug.php?id=66399&edit=1