Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128315
Precedence: bulk
MIME-Version: 1.0
References: <CAMU7irKj_SyyM2kVz4kEqjDK+ucc8uRP1amJgASTFRM+V+Ld3w@mail.gmail.com>
 <639dcf61-1b15-4381-aaff-54f0bd6bc23a@rwec.co.uk>
In-Reply-To: <639dcf61-1b15-4381-aaff-54f0bd6bc23a@rwec.co.uk>
Date: Wed, 30 Jul 2025 08:54:11 +0200
Message-ID: <CAMU7irJmUpnqCWHeOxJVmXu7HgaKPmsiPYcx=cc-Y2g-R8gWjg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Add "is_representable_as_float()" and
 "is_representable_as_int()" functions
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

>> The value is a float that is not NaN or infinity
>
> It feels a bit odd to have a value where is_float($v) would be true, but =
is_representable_as_float($v) would be false. I'd be interested to understa=
nd the thinking behind this case.

As the strings =E2=80=9CINF=E2=80=9D and =E2=80=9CNAN=E2=80=9D can't be cas=
t as floats directly, I
think it's safer to return false on these extreme values. See
https://3v4l.org/TabMK#vnull for the cast example.

> I suggest removing that sentence and example completely. There is nothing=
 the function can or should do differently on different platforms.

You are right, it's misleading. I'll update the RFC accordingly.

> This one is fair enough, but I'd suggest tweaking the example slightly to=
 avoid the same problem with different inputs: on a 64-bit build, 2**31 alr=
eady is an integer, so it's trivially true. So either force a floating poin=
t input:
>
> is_representable_as_int(2.0**31); // true on 64-bit platforms, false on 3=
2-bit platforms
>
> or, perhaps clearer, use an out-of-range string input:
>
> is_representable_as_int('2147483648'); // true on 64-bit platforms, false=
 on 32-bit platforms

I'll also update accordingly. Thank you!

Best,
Alexandre Daubois