![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#17725 closed defect (bug) (wontfix)
wp_convert_hr_to_bytes() fails on large numeric values
| Reported by: | hakre | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Formatting | Version: | 2.3 |
| Severity: | trivial | Keywords: | needs-refresh |
| Cc: | Focuses: |
Description
The wp_convert_hr_to_bytes() function exists to convert values in form of a memory setting into it's value in bytes.
By doing so, the function modifies the input value in every case. This modification has an issue with integer limits.
Whenever a value of $size is passed to the function that is in it's numerical part larger than PHP_INT_MAX, the input value will be capped to PHP_INT_MAX.
This is an integer overflow.
This applies as well when size has a shorthand ending specifier and it's numerical part is greater than PHP_INT_MAX.
To illustrate the problem on a 32 bit system:
$setting = '2147483648'; echo "'$setting' are ", wp_convert_hr_to_bytes($setting), " bytes.\n"; // '2147483648' are 2147483647 bytes.
It shows that the last byte is missing. Every other byte on top will be capped as well. The number of bytes given are a value equally to '2G'.
Solution: Input values should not be capped to int but to float which has allows higher values.
Attachments (3)
Change History (12)
#3
@
12 years ago
- Keywords needs-refresh added; has-patch removed
Needs to refresh to update the comment block for the function as they've been updated in core since this patch was made
#7
@
12 years ago
- Severity normal → trivial
I would be curious if 32-bit servers are even capable of receiving uploads larger than 2 GB. This strikes me as a very trivial issue.
#8
@
12 years ago
http://php.net/manual/en/ini.core.php
This even specifies a signed integer limit on post_max_size > upload_max_filesize, both of which are directly referenced in wp_max_upload_size().
The description, "It shows that the last byte is missing," is invalid considering PHP will limit the post payload to 2GB - 1 in that situation.
I vote wontfix. However, it might be helpful to update the docs to indicate this function is specifically tied to the INI syntax and corresponding limitations.
#9
@
12 years ago
- Milestone Awaiting Review
- Resolution → wontfix
- Status new → closed
The logic in the new patch is also var too obtuse (and fragile).
Hypothetically, this function should indeed work for any human-readable size value, based on what it is named and currently documented. This works fine for values using "K", "KB", or "KiB" etc. It should hypothetically be able to convert a 500GB hard drive to bytes. But in practice, if this fails on a 32-bit system, I don't really care.
Use float instad of int.