php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76587 array_column gives incorrect result if $indexKey selects a float
Submitted: 2018-07-06 13:14 UTC Modified: 2018-11-18 00:23 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: rowan dot collins at gmail dot com Assigned: cmb (profile)
Status: Closed Package: Arrays related
PHP Version: 7.2.7 OS:
Private report: No CVE-ID: None
 [2018-07-06 13:14 UTC] rowan dot collins at gmail dot com
Description:
------------
When array_column is used with the $indexKey parameter, and the selected index is a float, it is ignored, and treated as an array-append operation.

This is unexpected, because attempting to use a float as a key would normally result in it being cast to either an integer or a string.

Note that this is similar to Bug #68553, where null keys are also treated as array-appends.

As with that bug, the polyfill implemented in userland behaves as expected. HHVM's implementation seems to cast all floats to integer, so float(2.5) becomes int(2) rather than string("2.5").

Test script:
---------------
$a = [
    [ 'foo' => 1.0 ],
    [ 'foo' => 2.5 ],
    [ 'foo' => 3 ],
    [ 'foo' => '4' ],
];
var_dump(array_column($a, 'foo', 'foo'));

Expected result:
----------------
array(4) {
 [1] => float(1)
 ["2.5"] => float(2.5)
 [3] => int(3)
 [4] => string(1) "4" 
}

Actual result:
--------------
array(4) { 
 [0] => float(1)
 [1] => float(2.5)
 [3] => int(3)
 [4] => string(1) "4" 
} 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-07-06 13:56 UTC] cmb@php.net
-Status: Open +Status: Analyzed
 [2018-07-06 13:56 UTC] cmb@php.net
I can confirm the described behavior: <https://3v4l.org/Yvaup>.
However, I'm not sure that qualifies as bug, since the docs[1]
state:

| This value may be the integer key of the column, or it may be
| the string key name.

Anyhow, if we would change the current behavior (BC break!), we 'd
had to adapt this code[2] (cast FLOAT to INT), or perhaps even
treat the $column_key parameter in the same way and adapt
array_column_fetch_prop()[3].

[1] <http://php.net/manual/en/function.array-column.php>
[2] <https://github.com/php/php-src/blob/af341213f73650b28b74b374501d84060eb604ab/ext/standard/array.c#L4177-L4182>
[3] <https://github.com/php/php-src/blob/af341213f73650b28b74b374501d84060eb604ab/ext/standard/array.c#L4111-L4115>
 [2018-07-06 13:57 UTC] danack@php.net
The issue seems to be the code in array_column appears to not cater for floats at all and to instead use add_next_index_zval to add the next value, if the key was going to be a float.


if (Z_TYPE_P(zkeyval) == IS_STRING) {
	zend_symtable_update(Z_ARRVAL_P(return_value), Z_STR_P(zkeyval), zcolval);
} else if (Z_TYPE_P(zkeyval) == IS_LONG) {
	add_index_zval(return_value, Z_LVAL_P(zkeyval), zcolval);
} else if (Z_TYPE_P(zkeyval) == IS_OBJECT) {
	zend_string *tmp_key;
	zend_string *key = zval_get_tmp_string(zkeyval, &tmp_key);
	zend_symtable_update(Z_ARRVAL_P(return_value), key, zcolval);
	zend_tmp_string_release(tmp_key);
} else {
	add_next_index_zval(return_value, zcolval);
}


Possibly related:
https://bugs.php.net/bug.php?id=68553



Just to note, even if array_column worked as it possibly should - for your case it still won't give you the expected output as floats get cast to ints for array keys:

```
$foo = [
    2.5 => 'whatever'
];
var_dump($foo);

//output is: 
array(1) {
  [2] =>
  string(8) "whatever"
}
```


As such - it's possible to see why that behaviour was chosen. Using add_next_index_zval avoids overwriting columns in some cases......but, ewwww - not all: 


```
$a = [
    [ 'foo' => 0.5 ],
    [ 'foo' => 0 ],
    [ 'foo' => '0' ],
];

var_dump(array_column($a, 'foo', 'foo'));

// output is
array(1) {
  [0]=>
  string(1) "0"
}
```
 [2018-07-06 14:41 UTC] rowan dot collins at gmail dot com
Hm, good spot on the expected behaviour; I'd based it on the polyfill, but cast-to-int (which is what HHVM's implementation does) is indeed the more consistent behaviour; the cast-to-string could therefore be considered a bug in the polyfill.

My actual use case involved a database result set where I'd used FLOOR(some_calculation), which resulted in values like float(1.0), so either behaviour would have been fine. I worked around the problem by using CAST(some_calculation AS INT) instead.

The problem with the current implementation is that it has the effect of *completely ignoring* the $indexKey value, which is extremely surprising, and I can't see why that would be desirable (if you wanted the keys generated sequentially, you would omit the $indexKey parameter).

As for overwriting values, that's inevitable because a) you could have any number of identical index values anyway, and b) there will always be cases like int(0) and string("0") which are not distinguished.
 [2018-07-24 03:39 UTC] laruence@php.net
-Status: Analyzed +Status: Feedback
 [2018-11-18 00:23 UTC] cmb@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: cmb
 [2018-11-18 00:23 UTC] cmb@php.net
Since this has been fixed by laruence's commit, I'm closing this
ticket.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Jun 20 04:01:26 2019 UTC