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 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.

[mvorisek]

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.)

This can be easily solved by a macro/function and assertion that the input is no bigger than max. alloved value of size_t.

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.

My usecase is IoT on embedded 32-bit ARM. I belive such usage is hard to be tracked by any stat as the php-src is usually downloaded/compiled once and distributed on many devices by copying.

[iluuu1994]

This can be easily solved by a macro/function and assertion that the input is no bigger than max. alloved value of size_t.

The hard part is not fixing the code, it's finding all the cases that need fixing.

[derickr]

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

That's not been universally true for quite some time, and time_t is 8 bytes on most modern linux variants:

derick@gargleblaster:/tmp/timet$ cat main.c
#include <time.h>
#include <stdio.h>

int main(void) {
    printf("%d\n", sizeof(time_t));
}

derick@gargleblaster:/tmp/timet$ gcc -o test main.c

derick@gargleblaster:/tmp/timet$ ./test
8

It is not relevant in the Date/Time case for PHP any way, as the DateTime/DateTimeImmutable classes have been 8-byte representations since PHP 5.2.

[cmb69]

[…] , and time_t is 8 bytes on most modern linux variants:

Maybe we should change the Windows behavior then: https://github.com/php/php-src/blob/242b9438ea1f9a7f72afe1db5cd8f3bf80152dc5/win32/build/confutils.js#L3239-L3246

[github-actions[bot]]

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]

not stale and unified integer support is important for small IoT devices

[iluuu1994]

That's not been universally true for quite some time, and time_t is 8 bytes on most modern linux variants:

What's still true is that \DateTimeInterface::getTimestamp() would stop working.

I'm not sure how we should proceed here. I don't see a reliable way for this to work, especially given what @cmb69 said ("most C APIs would still not support that"). Essentially all calls to external C APIs that take int would need to do overflow checking. And then do what? It's not clear what the correct behavior on overflow would be. And if it's never safe to have integers over what 32-bit can represent then why even bother?

[TimWolla]

Is the stale bot working correctly? It did not remove the label.

[TysonAndre]

What's still true is that \DateTimeInterface::getTimestamp() would stop working.

yes, that and time() were what I was referring to, not linux itself

[cmb69]

Essentially all calls to external C APIs that take int would need to do overflow checking. And then do what? It's not clear what the correct behavior on overflow would be.

ValueError – back to square one.

Is the stale bot working correctly? It did not remove the label.

I don't think this is implemented. So far, the bot only reminds about going stale in a while, and finally closes as stale.

[iluuu1994]

@TimWolla @cmb69 The label should get removed the next time the action runs, so on the next day.

[TimWolla]

@TimWolla @cmb69 The label should get removed the next time the action runs, so on the next day.

@iluuu1994 Ah, makes sense. We probably should run it more than once per day then (once per hour?). It runs for just a few seconds anyway, so we won't burn the planet.

[iluuu1994]

I'm not sure that if we executed it more frequently we'd need to properly configure an API token to avoid running into rate limiting issues (unless that happens automatically for GitHub actions?). At least the docs says something like that if I remember correctly. Since the issue is only closed 7 days later I'm not sure if waiting for the label to get removed on the next day does any harm, except maybe cause some confusion like here :slightly_smiling_face:

[nikic]

I think this would make sense if it is part of full bigint (in the sense of arbitrary-precision integers) support.

[github-actions[bot]]

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.

[github-actions[bot]]

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.

[github-actions[bot]]

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.