Too big integer token should produce a warning

[mvorisek]

Description

<?php

$u = 1234567890123456789012345678901234567890;
var_dump($u);

https://3v4l.org/aedla

Integer token, number specified in the code without dot or scientific notation, should produce a warning at least.

This is especially usefull for 32-bit/embedded php usage where implicit conversion might be not wanted.

[cmb69]

ints generally overflow to float silently. I don't like that, but that's what we have. And if we want to change that, I suggest to introduce bigints (maybe like https://wiki.php.net/rfc/bigint).

[cmb69]

Somewhat related to #8016.

[TysonAndre]

ints generally overflow to float silently. I don't like that, but that's what we have. And if we want to change that, I suggest to introduce bigints (maybe like https://wiki.php.net/rfc/bigint).

Also somewhat related to #5921 (for ints in bases that are powers of 2) - I'd stopped work on that since I wasn't sure if anyone was in the middle of a native bigint proposal, and don't plan to continue on 5921, feel free to reuse any parts you find useful. The handling of 32-bit edge behavior was one thing I hadn't defined/finished in that PR.

• e.g. the fact that 0x80000000_00000000 currently overflows silently to float on 64-bit platforms seemed like it'd be more compelling to warn about or deprecate

php > var_dump(0x80000000_00000000);
float(9.2233720368548E+18)
php > var_dump(0x70000000_00000000);
int(8070450532247928832)

[mvorisek]

Thank you and TBH I am not sure if bigint is solution for everything. Bigint would be nice in php, but almost all integratings with database, APIs, will still be usually limited to signed/unsigned int/long long. But 32-bit platform should definitely use the same/64-bit integer as 64-bit platform does, platform should simply not matter - #8016.

#5921 is good example - hex constants - where overflow is not desired. IMHO the format dec/binary/hexdec should not matter and we should simply emit a warning if the parsed integer cannot be represented. In PHP 9.0 it can be a hard parse/compile error.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[mvorisek]

Issues like #10598 confirm this problem. I belive arbitrary-precision integers cannot be supported in all places, so I would say #5921 is welcomed solution to this issue.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.