Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104360
MIME-Version: 1.0
References: <C8CF5498-7451-4BDC-935F-17D010DBA6B6@bk.ru> <D74A9128-95B5-4F35-BD89-C474C2FF923A@bk.ru>
 <C430C088-8A48-4124-9814-9F39A3B2E5C6@gmail.com> <11BCF7F8-4AEE-43FE-9D26-7D64C54EA382@gmail.com>
 <20.B2.14408.0FE57A95@pb1.pair.com>
In-Reply-To: <20.B2.14408.0FE57A95@pb1.pair.com>
Date: Tue, 12 Feb 2019 13:22:07 +0100
Message-ID: <CAF+90c9R=D8nQWs-EY02XvXRhmfC-SiOv3duatcLu+w+4KUF=A@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003e40e60581b17a2d"
Subject: Re: [PHP-DEV] Re: [Request][Discussion] Double value as array key improvement
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003e40e60581b17a2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 31, 2017 at 2:58 AM Andrea Faulds <ajf@ajf.me> wrote:

> Hi there,
>
> Andrew Nester wrote:
> >
> >
> > Hello internals!
> >
> > I was working on solution for the problem of double to int conversion
> for array indices and would like to create an RFC for proposed solution -
> emitting warning when integer overflow happens during double to int
> conversion.
> >
> > Does it look like good idea?
> >
> > Thanks!
> >
>
> It's certainly an improvement over silently truncate-wrapping like at
> present.
>
> But one question I might have is whether there's any benefit to it just
> being a warning rather than an Error. Surely nobody would rely on this
> behaviour? I can't imagine a use-case where it doing % 2^64 on your
> indices is helpful. Who would want the code execution to continue beyond
> that point? Will someone want to silence this error?
>
> Compare how the `int` type declaration on userland functions handles
> floats like these: it throws a TypeError. Internal functions *do* throw
> a warning, but they don't execute their body and return NULL instead
> (they do throw a TypeError in strict mode).
>
> If you threw some kind of Error instead, I can't imagine it causing
> backwards-compatibility problems in practice, and at least personally, I
> think it would be the better choice. But I wrote the RFC that made
> passing floats > PHP_INT_MAX or < PHP_INT_MIN to functions with integer
> parameters produce those errors, so of course I'd say that=E2=80=A6
>
> Anyway, thanks for bringing this up! It's something that I've wanted to
> fix since a long time ago and had forgotten about.
>

(Bumping an old discussion here)

I think the parallel with how we handle this for int parameters is a good
one, and it would make sense to throw a TypeError when trying to use an out
of range float key in an array. I'm slightly uneasy about the
value-dependent behavior (e.g. your code might start throwing because the
user entered a particularly large value somewhere). However, the argument
applies to parameter handling in the same way, and as far as I know our
behavior there has never proven to be a problem. And as using an out of
range value essentially produces a nonsense result (say a negative number
though your input was positive), I think pointing out the issue with a
TypeError would be a win anyway...

Nikita

--0000000000003e40e60581b17a2d--