#3046 - Drop 32-bit support (on hold)
-
By Chris Graham
- Added
- 5 views
| Identifier | #3046 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Drop 32-bit support (on hold) |
| Status | Open |
| Tags |
Risk: Deprecates functionality (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | Linux distributions have recently dropped 32-bit support.
Windows 10 still supports 32-bit. However, practically users are less and less likely to run on 32-bit now as there's a 4GB RAM limit (more like 3GB in practice). There's a reason we only want 64-bit... the year 2038 problem. That's the maximum timestamp we can store in 32-bit PHP. It would be 2106 if PHP supported unsigned integers, but it doesn't. It's already a problem, I saw an error mail from a user failing to save a probation time into the DB far in the future. It's not easy to reproduce that right now because it only let's 10 years ahead, but you can save it 10 years ahead, then put it 10 years ahead again. So, at some point we should put a requirement in the installer/checks-system to only install on 64-bit systems, and add it to our minimum requirement. Then we need to upgrade all the 'TIME' fields in people's database from 'unsigned int' to 'bigint' (note 'unsigned' is MySQL only -- non-MySQL drivers are already on bigint). EDIT: actually on MySQL's end we have a 2106 problem due to the unsigned, which is far better. Still worth fixing, but delays the urgency of this issue as anyone on 64 bit machines is protected until nearing 2106 already due to this. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
So we probably have to wait a while until we can realistically make a change.
OR, we could just throw out a warning at installation and say we don't support 32-bit officially and why, but let it continue to work for 99.999% of things.
If a user enters a huge value, PHP will lock it to it's maximum integer size.
However, we are using ints, not bigints, so it overflows trying to save into the DB.
Note that we can use bigints in MySQL even if MySQL is installed as 32 bit. So we don't need to check if MySQL is 64 or 32 bit at all.
- Desktop processors have not been 32-bit for at least 15 years
- ARM is dropping 32-bit support for new CPU designs in 2022
- Windows no longer supports 32-bit installs
- Ubuntu dropped 32-bit library support then back-tracked (so people can run old games)
- Linux Mint dropped 32-bit library support
- Mac migrated ages ago
So to me the only likely situations of running 32 bit would be:
- Older Raspberry Pis running 32-bit ARM chips
- People who weirdly install 32-bit PHP on 64-bit Windows (a build is still provided as of this date)
Probably we can leave this a few more years, we're still 17 years from 2038, so it's still unlikely people are going to use dates that far ahead.