This is an old revision of the document!
PHP RFC: Fix overflow in octal parsing
- Version: 1.0
- Date: 2016-04-12
- Author: Sara Golemon pollita@php.net
- Status: Under Discussion
- 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 overflows value of {} truncated to {}”
- 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.
Backward Incompatible Changes
Any fix for this overflow behavior means a BC break, by definition. Thus the RFC.
Proposed PHP Version(s)
7.1
Proposed Voting Choices
Following a discussion period, a multi option vote will be opened for the above options (mas o menos). Likely requiring a 2/3rd + 1 majority.
References
The subject of this RFC is Bug#71994