|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52899 Incorrect array key cast (string to integer) when key > PHP_INT_MAX
Submitted: 2010-09-21 11:50 UTC Modified: 2010-09-29 17:37 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: thorn at slonik dot sk Assigned:
Status: Duplicate Package: Scripting Engine problem
PHP Version: 5.2.14 OS: Linux 32-bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: thorn at slonik dot sk
New email:
PHP Version: OS:


 [2010-09-21 11:50 UTC] thorn at slonik dot sk
When using string as an array's key which looks like integer - the key is converted to integer. That is ok for integers not bigger than PHP_INT_MAX.

But when the key is: PHP_INT_MAX < key < 3000000000 (on 32-bit system)
the key is converted to incorrect integer (it overflows :)

The key should remain string and not be converted to incorrect int.

See test script, expected and actual results.

A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08").

Related bugs:

Test script:
$array['2000000000'] = 1; // ok
$array['2147483647'] = 2; // ok
$array['2147483648'] = 3; // incorrect
$array['2999999999'] = 4; // incorrect
$array['3000000000'] = 5; // ok again

Expected result:
array(5) {

Actual result:
array(5) {
  [-2147483648]=> // int key overflow
  [-1294967297]=> // int key overflow


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-21 13:54 UTC]
Can you give more details about your system? Are you using distro binaries?

I can't reproduce this:

root@router:~# php
$array['2147483648'] = 3;
array(1) {
root@router:~# php -v
PHP 5.2.14 (cli) (built: Aug 18 2010 17:16:15)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
root@router:~# uname -a
Linux router 2.4.36 #340 Sun Jul 27 20:07:55 CEST 2008 mips unknown
 [2010-09-21 15:54 UTC] thorn at slonik dot sk
I'm using gentoo linux (no distro binaries)
$ php -v
PHP 5.2.14-pl0-gentoo (cli) (built: Sep 17 2010 12:47:23) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
$ uname -a
Linux gloriosa 2.6.35-tuxonice-r1 #1 SMP Wed Sep 1 08:59:13 CEST 2010 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
 [2010-09-21 17:41 UTC]
-Status: Open +Status: Feedback
 [2010-09-21 17:41 UTC]
Can you try with a vanilla version of PHP 5.2.14?

By inspection, I don't see how this can happen. Most likely it's due to a Gentoo patch.
 [2010-09-22 09:08 UTC] thorn at slonik dot sk
-Status: Feedback +Status: Open
 [2010-09-22 09:08 UTC] thorn at slonik dot sk
I opened a gentoo bug:

I tried my test script on same machine with windows and it works correctly.

I'm compiling 5.3.3 now to see if it's any different.
Will post results later.
 [2010-09-22 13:28 UTC] thorn at slonik dot sk
I tried 5.3.3 but the results are same as with 5.2.14.
 [2010-09-24 09:09 UTC] thorn at slonik dot sk
-Status: Open +Status: Closed
 [2010-09-24 09:09 UTC] thorn at slonik dot sk
Since you cannot reproduce it and I don't have access to other 32-bit machine with linux & php I close this bug.

I'd conclude with: It seems to be gentoo specific bug.
Even though they could not help as of yet. :(
 [2010-09-29 17:37 UTC]
-Status: Closed +Status: Duplicate
 [2010-09-29 17:37 UTC]
The relevant code is here:

It's not the most beautiful thing and it actually relies on undefined behavior, namely that an integer overflow will result in a wrap-around (signed integer overflow has undefined behavior as per the C standard). It relies on getting a negative number to detect the overflow.

However, it explicitly tests for the sign of the result, so it would appear it could never allow a negative number without the string starting with "-". But apparently, that check is optimized away, depending on compiler flags.

Duplicate of bug #51008.

The Debian patch is probably the way to go.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jul 25 05:01:29 2024 UTC