[php-src] Issue #8016: Unify `integer` range across platforms

From: Date: Mon, 14 Feb 2022 18:35:49 +0000
Subject: [php-src] Issue #8016: Unify `integer` range across platforms
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-239781@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/8016 Comment Author: TysonAndre 32-bit support also 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 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 ```c // 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 https://github.com/php/php-src/pull/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.

« previous php.bugs (#239781) next »