php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66399 Inconsistent runtime support for integer binary/hex syntax
Submitted: 2014-01-03 11:46 UTC Modified: 2014-12-30 10:42 UTC
From: benjamin at zikarsky dot de Assigned: dmitry (profile)
Status: No Feedback Package: Strings related
PHP Version: 5.5.7 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2014-01-03 11:46 UTC] benjamin at zikarsky dot de
Description:
------------
While PHP's support for hexadecimal and binary (>=5.4) integer literals works fine at "compile"-time, it is inconsistent/lacking at runtime. E.g. in strings.

 - is_numeric($v) detects hexadecimal format but not the binary version
 - casting to int (both with (int) and intval($v)) is not supported for either format

I am not sure if this is a bug/missing feature or unwanted behavior. I think it should be at least consistent for is_numeric. 


Test script:
---------------
<?php

$bin = "0b100";
$hex = "0x04";

var_dump((int) $bin);
var_dump((int) $hex);

var_dump(is_numeric($bin));
var_dump(is_numeric($hex));

var_dump(intval($bin));
var_dump(intval($hex));

Expected result:
----------------
int(4)
int(4)
bool(true)
bool(true)
int(4)
int(4)

Actual result:
--------------
Tested with:

PHP 5.5.7 (cli) (built: Jan  3 2014 11:33:48)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies


Output: 

int(0)
int(0)
bool(false)
bool(true)
int(0)
int(0)





Patches

inconsistent-bin-hex-handling.patch (last revision 2014-01-03 14:25 UTC by krakjoe@php.net)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-01-03 13:39 UTC] krakjoe@php.net
The following patch has been added/updated:

Patch Name: inconsistent-bin-hex-handling.patch
Revision:   1388756384
URL:        https://bugs.php.net/patch-display.php?bug=66399&patch=inconsistent-bin-hex-handling.patch&revision=1388756384
 [2014-01-03 13:41 UTC] krakjoe@php.net
Patch attached ... while this has the desired outcome, I've not tested and don't know if it introduces inconsistencies elsewhere. 

I would assume there is some non-obvious reason this wasn't done in the first place ?

<?php

$bin = "0b100";
$hex = "0x04";

var_dump((int) $bin, (int) $hex);
var_dump((double) $bin, (double) $hex);

var_dump(is_numeric($bin));
var_dump(is_numeric($hex));

var_dump(intval($bin), intval($hex));
var_dump(floatval($bin), floatval($hex));

Yields:

int(4)
int(4)
float(4)
float(4)
bool(true)
bool(true)
int(4)
int(4)
float(4)
float(4)
 [2014-01-03 13:42 UTC] krakjoe@php.net
All Zend and ext/standard/string tests passing ...
 [2014-01-03 13:52 UTC] krakjoe@php.net
-Assigned To: +Assigned To: dmitry
 [2014-01-03 13:52 UTC] krakjoe@php.net
Dmitry, assigning to you to get some attention, this appears quite important to me. I'm not able to say if the patch has adverse performance impact or introduces some strangeness you purposely left out. 

It looks good to me ?
 [2014-01-03 14:13 UTC] krakjoe@php.net
The following patch has been added/updated:

Patch Name: inconsistent-bin-hex-handling.patch
Revision:   1388758398
URL:        https://bugs.php.net/patch-display.php?bug=66399&patch=inconsistent-bin-hex-handling.patch&revision=1388758398
 [2014-01-03 14:15 UTC] krakjoe@php.net
The following patch has been added/updated:

Patch Name: inconsistent-bin-hex-handling.patch
Revision:   1388758509
URL:        https://bugs.php.net/patch-display.php?bug=66399&patch=inconsistent-bin-hex-handling.patch&revision=1388758509
 [2014-01-03 14:25 UTC] 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
 [2014-01-03 18:19 UTC] 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 20:14 UTC] 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-04 00:44 UTC] yohgaki@php.net
Added this issue to RFC to track.
https://wiki.php.net/rfc/comparison_inconsistency
 [2014-01-04 08:06 UTC] 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-09 06:37 UTC] dmitry@php.net
-Status: Assigned +Status: Feedback
 [2014-01-09 06:37 UTC] dmitry@php.net
I would agree to remove hex numbers support in is_numeric_string() (in PHP-5.6), but it really may break some code.
 [2014-12-30 10:42 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Sep 25 21:03:35 2021 UTC