What I expect:

1. I call backup_migrate_to_bytes() with a strictly numeric value (inside a string), like so: backup_migrate_to_bytes('104857600').
2. The function returns the input as an integer: 104857600.

What I get:

1. I call backup_migrate_to_bytes() with a strictly numeric value (inside a string), like so: backup_migrate_to_bytes('104857600').
2. The function removes the last digit from the input, then returns the result as an integer multiplied by 1024 times 1024: 10995116277760.

The backup_migrate_to_bytes() is for converting php.ini style 'memory_limit' values into an integer value representing bytes. The PHP manual says, amongst others: "When an integer is used, the value is measured in bytes."

Possible php.ini values:
-1, reserved, meaning no memory limit.
43414, meaning 43414 bytes.
45M, meaning 45 megabytes, i.e. 47185920 bytes.
2G, meaning 2 gigabytes, i.e. 2147483648 bytes.

I feel that if the input of backup_migrate_to_bytes() is strictly numeric, then the output should be the input. I.e.:

default: 
  return $from;

How this bug gets dealt with also depends on the outcome of "A non-numeric value encountered" in backup_migrate_to_bytes(), which is why I marking that one as a dependency.

Fixing this could cause problems if:

a) this lowers the memory limit on production sites.

b) other modules or themes have been calling backup_migrate_to_bytes() and expecting certain return values.

Comments

brankoc created an issue. See original summary.

BrankoC’s picture

I got the parent/child relation wrong.