Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43438
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: <0A5E619CF62F490D9FD435B5CADFCB13@pc1>
To: <internals@lists.php.net>,
	"Lukas Kahwe Smith" <mls@pooteeweet.org>,
	"Rasmus Lerdorf" <rasmus@lerdorf.com>
Cc: "Dmitry Stogov" <dmitry@zend.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>
Date: Mon, 23 Mar 2009 09:22:29 -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] 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 Lukas,

----- Original Message -----
From: "Lukas Kahwe Smith"
Sent: Monday, March 23, 2009

>
> 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)?

Yeah, you understood that the subject about Bug #45877 is different. :-)

Rasmus' issue is the "DVAL_TO_LVAL() change, different behavior" stuff I've 
been bringing up for a while.  My last message from 9 days ago with all info 
either in it or the linked previous messages: 
http://marc.info/?l=php-internals&m=123704111325725&w=2  I hoped there might 
be some discussion about what should be expected, and how to ensure desired 
behavior.  I kinda hit a limit with what I can do and test, without being 
able to verify things on other platforms.

However, Rasmus is talking about a change in 5.2, and DVAL_TO_LVAL() didn't 
change there, but his symptoms are the same, at least.

Of course, my message/patch from a week ago [1] to extend bitwise and 
modulus operators (on 32-bit platforms) would help with my original problem 
caused by DVAL_TO_LVAL(), as well as issues others may run into (like Bug 
#46579).  Regardless, the current DVAL_TO_LVAL() definitely doesn't behave 
consistently across platforms [2], so it should be updated somehow.

I don't think there's much to worry about with these things and the RC 
(after).  It's not like either of them should "wreak havoc" with code by 
changing how large numbers are handled (isolated, easy to check results, 
etc.).

[1] http://marc.info/?l=php-internals&m=123722650225792&w=2
[2] http://marc.info/?l=php-internals&m=123496364812725&w=2

> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

- Matt