Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.151.69.1 cause and error)
Message-ID: <9449C66530F54397B9D3D66B21BE2B9F@pc1>
To: <internals@lists.php.net>,
	"Dmitry Stogov" <dmitry@zend.com>,
	"Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Rasmus Lerdorf" <rasmus@lerdorf.com>,
	=?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
References: <1113CE12226949C2939A31971420991F@pc1> <49C0A7C7.8000804@zend.com> <12E613FAA1C9422B948F00B61AD32366@pc1> <49C134E5.7020706@zend.com> <49C29EEF.9010702@lerdorf.com> <6418ED1D-5CC3-4CA9-8C06-80FBE9864190@pooteeweet.org> <49C79ACF.50306@zend.com>
Date: Mon, 23 Mar 2009 09:45:49 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: array kindex overflow issue Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
From: php_lists@realplain.com ("Matt Wilmas")

Hi Dmitry,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Monday, March 23, 2009

>
> Lukas Kahwe Smith wrote:
>>
>> On 19.03.2009, at 20:37, Rasmus Lerdorf wrote:
>>
>>> 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.
>>
>>
>> If I understood it properly, the issue Matt/Dmitry are working on is 
>> something else. So where do we stand on the issue Rasmus's notes (is 
>> there a ticket for this one already)?
>
> It's related to another Matt's proposal which cares about float to long 
> conversion.
>
> Matt, what will we get with your patch and code above?
> [LONG_MAX] => blah?

You mean from 3500000000 as a double?  No, I'm going for the overflow 
behavior that most people have been getting in 5.2 (before 5.3's 
DVAL_TO_LVAL() change), though that overflow isn't guaranteed (which I'm 
trying to do).  So:

var_dump(array(3500000000 => 1));

array(1) {
  [-794967296]=>
  int(1)
}

However, the array example may not be the best, since DVAL_TO_LVAL() *is 
not* used in 5.2 for double array keys, but a simple (long) cast, which 
could behave differently than using PHP's (int) cast on the same value.

I originally brought up the double->long conversion not for array keys, but 
because I wanted overflow to keep the least significant bits when using the 
bitwise & operator.  Last year's message (linked in the recent patch 
message): http://marc.info/?l=php-internals&m=120799720922202&w=2

> Thanks. Dmitry.

- Matt