Unify `integer` range across platforms

[mvorisek]

Description

Currently integer type is platform dependent and has limited range on 32b platforms.

This is a feature request for PHP 9.0 to unify the range to -2^63 - 2^63-1.

I belive the unified behaviour is worth of a small performance sacrifice. Performance is every day cheaper and the real beaty of PHP is that the language abstracts the underlaying system differences.

[cmb69]

I don't think that would make much sense. Even if we would support 64bit signed integers on 32bit platforms, most C APIs would still not support that (e.g. several file system functions which would need to be changed to LFS). Furthermore, it is even doubtful whether 32bit support generally makes much sense at this point. And it still wouldn't solve the overflow issues (int → float), which might be more elegantly solved by bignum support.

At the very least, this would require an RFC. Do you want to pursue the RFC process?

[mvorisek]

My primary motivation is unified behaviour. One of many examples are IDs. Most php apps use integer type for ID (for ex. for database records). Currently when these apps are run on 32b php, they cannot handle big numbers and very often produce unexpected results as very few apps are tested against 32b platforms/binaries.

32b platform/CPU is commonly used for IoT or other embedded areas.

Another arguments for this change is that php uses unified/64b precision for floating point numbers already.

Also, other higher level/weakly typed languages, such lua, use 64b integers across all platforms.

I understand this definitely requires an RFC, but I belive the impact on the end user, considering the slight performance decrease, is only positive.

I am starting the RFC process here to gather the feedback from all sides and would be also grateful if someone wants to help with the RFC itself and/or the implementation. Thanks!

[TysonAndre]

32-bit support also

1. Has the year 2038 problem (https://en.wikipedia.org/wiki/Year_2038_problem), e.g. in 2028 we'll start overflowing when computing dates 10 years in the future
2. Has issues with files 2GB or larger (PHP_INT_MAX)

Currently, php-src and a lot of pecl code relies on the fact that sizeof(zend_long) <= sizeof(size_t) by the macros detecting the native int size. This assumption is documented in Zend/zend_range_check.h and zend_long is defined in Zend/zend_long.h

// Zend/zend_range_check.h
#if SIZEOF_INT < SIZEOF_SIZE_T
/* size_t can always overflow signed int on the same platform.
   Furthermore, by the current design, size_t can always
   overflow zend_long. */
# define ZEND_SIZE_T_CAN_OVFL_UINT 1
#endif

I expect a lot of code expecting size_t offset to potentically overflow if sizeof(zend_long) > sizeof(size_t) without more work (e.g. emalloc, malloc, helper functions using those, native C library functions, etc.)

---

The last time changes affecting 32-bit support was brought up, @nikic mentioned it would be a good idea to see if php was commonly used with 32-bit systems were.

I personally don't
have any idea how common PHP is used on 32-bit systems (are there any stats
on that? From OS package installs, composer, etc?) and why it is used
there. I know that running PHP on 32-bit is often faster, but I'm not sure
if people explicitly chose to use 32-bit for that reason.

---

Furthermore, it is even doubtful whether 32bit support generally makes much sense at this point. And it still wouldn't solve the overflow issues (int → float), which might be more elegantly solved by bignum support.

This was brought up in https://externals.io/message/111372#111374 about #5930 - I'd closed that PR since GMP couldn't be always-enabled due to licensing issues, and it didn't make sense to continue if I wasn't sure if anyone else was going to actively work on adding bigint as a native type (separate from is_object(), possibly separate from is_int()) at the time.