wp_convert_hr_to_bytes() fails on large numeric values

[hakre]

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.

[hakre]

Use float instad of int.

[hakre]

Related: #14889

[hakre]

Additional patch related to #14889

[hakre]

Update of .2: substr(-1) issues a warning on empty string.

[chriscct7]

Needs to refresh to update the comment block for the function as they've been updated in core since this patch was made

[DrewAPicture]

The docs were updated in [23437].

[miqrogroove]

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.

[miqrogroove]

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

[nacin]

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.