[php-src] Issue #8016: Unify `integer` range across platforms
| From: | TysonAndre | 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.