Open plstand opened 1 day ago
Yeah, that looks like an inadvertent behavioral change. @Girgias, thoughts?
I agree this is unintentional BC break, if someone is happy to "properly" implement a version of ZEND_STRTOUL()
that accepts 0b
, 0o
, and 0x
prefixes that would be nice. As that would probably fix most issues accross the codebase.
Description
Since d229a480ad5a63b029cc0d74ba251c5ddb8738e4 (#11910), zend_ini_parse_quantity_internal() rejects inputs in which 0x/0o/0b is followed by whitespace, a sign, or 0x/0o/0b, in order to prevent inputs such as
0x0x12
from being accepted as valid (see #11876). Unfortunately, while 0x and 0o cannot follow a base prefix within valid input, 0b can start a valid hexadecimal number with one leading zero, and such inputs are no longer accepted.As a suggested fix, zend_ini_consume_quantity() could be changed to not recognize "0b" or "0B", as ZEND_STRTOUL() should not recognize it (at least in the "C" locale). Better yet, do away with that function entirely and also fix #16886. Just check that a whitespace character, +, -, "0x", or "0X" does not immediately follow the base prefix (or check if the first two digits are valid for the base, or at least for hexadecimal). If the first digit is invalid, parsing should not continue (as is the case now), though if the second digit is invalid, the error should be reported as an unknown suffix (if last character) or as more than one character in suffix (if not last character) for consistency with how an invalid second digit is reported in the usual case.
The following code:
Resulted in this output:
But I expected this output instead:
PHP Version
PHP 8.5.0-dev
Operating System
No response