rfc:octal.overload-checking

This is an old revision of the document!


PHP RFC: Fix overflow in octal parsing

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.

  1. Do nothing. Some terrible application is relying on this behavior and there's no burning need to fix it.
  2. Retain the current overflow behavior, but raise a compile-time warning “Octal escape sequence overflows value of {} truncated to {}”
  3. 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

rfc/octal.overload-checking.1460514996.txt.gz · Last modified: 2017/09/22 13:28 (external edit)