Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43418
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <49C29EEF.9010702@lerdorf.com>
Date: Thu, 19 Mar 2009 15:37:19 -0400
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: Matt Wilmas <php_lists@realplain.com>, internals@lists.php.net,
        Lukas Kahwe Smith <mls@pooteeweet.org>,
        =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
References: <1113CE12226949C2939A31971420991F@pc1> <49C0A7C7.8000804@zend.com> <12E613FAA1C9422B948F00B61AD32366@pc1> <49C134E5.7020706@zend.com>
In-Reply-To: <49C134E5.7020706@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
From: rasmus@lerdorf.com (Rasmus Lerdorf)

So, what is the final conclusion on this one?  Are we at a combination
of Matt's and Dmitry's patches here?

I think we definitely need to fix this even in the 5.2 branch and get it
back to 5.1.x and earlier behavior.  I consider it a bug that:

 $arr[3500000000] = 'blah';
 print_r($arr);

results in:

 [-2147483648] => blah

if someone has written brand new 5.2-specific code that relies on this
weird behavior, then we will just have to bite the bullet and break that
code.  It is way more likely that people are relying on the earlier
behavior and will end up with subtle problems in 5.2.  I just had
someone at Yahoo get bitten by this when they upgraded from 5.1.x to 5.2.x.

-Rasmus