Table of Contents

PHP RFC: Type parsing modifications

Introduction

This RFC proposes changes in the ruleset used to filter and convert input arguments to internal functions.

History

The changes proposed here are based on concerns that arose during the discussion about scalar type hints.

While the discussion mostly opposed 'weak' and 'strict' mode proponents, each camp showing use cases to prove it was right, we decided to gather all these use cases and go exploring another way : search a single-mode compromise that would satisfy both camps.

It was soon clear that the strongest argument of strict-typing proponents was that 'weak' mode was way too permissive, allowing, for instance, true or '7 years' as integer value.

As the 'weak' mode of the proposed type hinting mechanism was based on the ZPP layer, and as everyone agreed any single-mode mechanism should keep using it, we decided to propose a new more restrictive ruleset to be implemented in ZPP.

Note: In the whole document, we use the 'ZPP' term as a union set including Z_PARAM macros, zend_parse_arg_xxx() functions, and zend_parse_parameters() as, whatever the ruleset, these mechanisms must keep implementing the same logic.

Proposal

Current ruleset

The ZPP ruleset authorizes implicit conversions for IS_NULL, IS_FALSE, IS_TRUE, IS_LONG, IS_DOUBLE, and IS_STRING zval types only.

Actually, it also implement a mechanism for (object -> string) but, as this one will remain unchanged, it will be ignored here.

The following table shows the current rules used to accept and convert an input zval through ZPP :

Zval type
ZPP type IS_NULL IS_FALSE IS_TRUE IS_LONG IS_DOUBLE IS_STRING
bool Yes (-> false) <native> <native> Yes (1) Yes (1) Yes (2)
long Yes (-> 0) Yes (-> 0) Yes (-> 1) <native> Yes (5) (3)
double Yes (-> 0.0) Yes (-> 0.0) Yes (-> 1.0) Yes <native> (4)
string Yes (-> “”) Yes (-> “”) Yes (-> “1”) Yes Yes <native>

The conversion of IS_STRING to int/float is done through _is_numeric_string_ex(). Among others, this function has the following behavior :

Proposed changes

In _is_numeric_string_ex() :

Future ruleset

This table shows a synthetic view of the resulting ruleset ('-' means 'Disabled'):

Zval type
ZPP type IS_NULL IS_FALSE IS_TRUE IS_LONG IS_DOUBLE IS_STRING
null <native> - - - - -
bool - <native> <native> Yes (1) Yes (1) Yes (5)
long - - - <native> (2) (3)
double - - - Yes <native> (4)
string - - - Yes Yes <native>

and the new behavior of _is_numeric_string_ex() :

Backward Incompatible Changes

Every change we propose here is a BC break.

Proposed PHP Version(s)

7.0.

RFC Impact

Every internal functions are potentially impacted.

Any code converting a string to a number is potentially impacted. If this cause an unacceptable BC break, we'll create a private copy of the function implemeneting (string -> int/float) and will reserve it for ZPP. As long as it is not clearly needed, we'll keep a common code for every string to number conversions in PHP.

To Opcache

None

New Constants

None

php.ini Defaults

Open Issues

Unaffected PHP Functionality

Future Scope

String to numeric conversion can be improved and accept a richer syntax.

Proposed Voting Choices

Requires a 2/3 majority.

Vote will be a single-choice yes/no vote.

Voting date is not planned yet.

Patches and Tests

Work in progress.

As soon as patch is available, extensive testing must be performed to evaluate overall BC breaks.

Implementation

After the project is implemented, this section should contain

  1. the version(s) it was merged to
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature

References

Rejected Features

Keep this updated with features that were discussed on the mail lists.