Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Date: Wed, 30 Jul 2014 06:48:27 +0100 (BST)
Reply-To: Andrea Faulds <ajf@ajf.me>
To: tjerk.meesters@gmail.com, yohgaki@ohgaki.net
Cc: internals@lists.php.net
Message-ID: <633025718.351649.1406699307462.open-xchange@app2.ox.registrar-servers.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Medium
Subject: Re: [PHP-DEV] signed long hash index for PHP7?
From: ajf@ajf.me (Andrea Faulds)



> On July 30, 2014 at 6:01 AM Tjerk Meesters <tjerk.meesters@gmail.com> wrote:
> 
> 
> Instead of doing that, why not simply disallow negative array indices to be
> used as integers?
> 
> In other words, negative indices are treated as if you had used strings so
> that it doesn't upset the the last numeric index kept in the array
> structure.
> 
> From what I can tell, it should be a pretty simply patch.
> 
> Thoughts?

That would make sense, but doesn't solve all edge cases as your maximum array
index is still more than 2 times the largest positive integer on 32-bit.

Perhaps we should completely change behaviour and forbid negative indices and
store indexes that are too large as strings? That would be the sanest way to go
IMO, solves all the edge cases, and makes ["999999999999999999999999999"] and
[999999999999999999999999999] consistent, resolving that long-existing
discrepancy.
--
Andrea Faulds