This is an old revision of the document!
PHP RFC: Fix overflow in octal parsing
- Version: 1.1
- Date: 2016-04-12
- Author: Sara Golemon pollita@php.net
- Status: Voting
- First Published at: https://wiki.php.net/rfc/octal.overload-checking
Introduction
Parsing of Octal (base 8) numbers contained in an interpolated string currently matches the pattern \\[0-7]{1,3}, that is a backslash followed by between one and three octits (numbers with an ordinal value between zero and seven). However, in order for a 3 octit number to fit within the space of a single character (one byte), the first octit is actually limited to base 4 (values from 0 to 3).
Currently, PHP does not guard against an overflow in the first octit of a 3 octit octal value, instead allowing the value to silently overflow without warning. Thus “\000” === “\400”, “\100” === “\500”, “\200” === “\600”, and “\300” === “\700”, and so on...
Proposal
This RFC seeks to decide which approach to take in addressing this undesired behavior.
- Do nothing. Some terrible application is relying on this behavior and there's no burning need to fix it.
- Retain the current overflow behavior, but raise a compile-time warning “Octal escape sequence overflow {} is greater than \\377”
- Limit octal numbers to \\[0-3]?[0-7]{0,2} meaning that sequences like “\456” would be parsed as octal 45 (decimal 37, e.g. a '%' character) followed by a literal 6
Options 2 and 3 may involve a deprecation/warning period followed by a permanent change.
Update: Between minimal comment and a lack of severity of this case. I've opted to initiate a vote for option 2. Produce a compile-time warning about value overflow.
Backward Incompatible Changes
New compile-time warning is raised on overflow during interpolation.
Proposed PHP Version(s)
7.1
Vote
Required 50% + 1 Voting Opened: 2016-04-29 21:30 UTC Closes: 2016-05-13 23:59 UTC
References
Implementation: https://github.com/php/php-src/compare/master...sgolemon:octal.warning
The subject of this RFC is Bug#71994