Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.41 as permitted sender)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=windows-1252
In-Reply-To: <633025718.351649.1406699307462.open-xchange@app2.ox.registrar-servers.com>
Date: Wed, 30 Jul 2014 14:50:22 +0800
Cc: yohgaki@ohgaki.net,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <204B9BC6-2DA9-452A-854B-7EA260A19543@gmail.com>
References: <633025718.351649.1406699307462.open-xchange@app2.ox.registrar-servers.com>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] signed long hash index for PHP7?
From: tjerk.meesters@gmail.com (Tjerk Meesters)


On 30 Jul, 2014, at 1:48 pm, Andrea Faulds <ajf@ajf.me> wrote:

>=20
>=20
>> On July 30, 2014 at 6:01 AM Tjerk Meesters <tjerk.meesters@gmail.com> =
wrote:
>>=20
>>=20
>> Instead of doing that, why not simply disallow negative array indices =
to be
>> used as integers?
>>=20
>> 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.
>>=20
>> =46rom what I can tell, it should be a pretty simply patch.
>>=20
>> Thoughts?
>=20
> 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.

Is that by design, a bug or something else entirely? Could you explain =
this edge case with some code?

>=20
> 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.

Forbidding negative indices is a bit harsh and imho quite unnecessary; =
turning =93out of range=94 indices into strings should work just fine =
afaict. Is there a reason why it shouldn=92t?

A compromise could be to allow string keys that would otherwise have =
converted into a negative integer, but disallow negative int/float =
explicitly.


> --
> Andrea Faulds