| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:deprecations_php_7_1 [2016/10/29 16:00] – Add each() nikic | rfc:deprecations_php_7_1 [2016/10/29 16:21] – nikic |
|---|
| * ''(binary)'' cast and ''%%b""%%'' literals | * ''(binary)'' cast and ''%%b""%%'' literals |
| * ''each()'' | * ''each()'' |
| | * ''assert()'' with string argument |
| | * ''$errcontext'' argument of error handler |
| |
| ===== Proposal ===== | ===== Proposal ===== |
| |
| Proposed action: As ''each'' is typically called within loops, throwing a deprecation warning for every call is likely not advisable. Instead, throw a deprecation warning on the first call for any given request. | Proposed action: As ''each'' is typically called within loops, throwing a deprecation warning for every call is likely not advisable. Instead, throw a deprecation warning on the first call for any given request. |
| | |
| | ==== assert() with string argument ==== |
| | |
| | The ''assert()'' function has two modes of operation: If it is passed something other than a string, it will assert that the value is truthy. If a string is passed, it will be run through ''eval()'' and assert will check that the result of the ''eval()'' is truthy. |
| | |
| | The reason for this behavior is that prior to PHP 7 this was the only way to prevent the assertion expression from evaluating. As of PHP 7, the ''zend.assertions'' ini option can be used to avoid evaluation of assertion expressions. As such, there is no longer a need for supporting implicitly evaluated string arguments. |
| | |
| | This behavior of ''assert()'' makes it easy to introduce subtle remote code execution vulnerabilities. Using ''assert($value)'' to check if a value is truthy opens an RCE vulnerability if there is any chance for ''$value'' to be a string. |
| | |
| | Proposed action: Throw a deprecation notice if ''assert()'' is used with a string argument. |
| | |
| | ==== $errcontext argument of error handler ==== |
| | |
| | Error handlers set with ''set_error_handler()'' are passed an ''$errcontext'' as the last argument. This argument is an array containing all local variables at the point the error was generated. |
| | |
| | This functionality is problematic for optimization, because the ''$errcontext'' can be used to modify all references and objects in the current scope. As far as I am aware, this functionality is barely used and the trade-off here is not worthwhile. If people wish to inspect the variable-state at the point of an error, they should use a proper debugger. |
| | |
| | Proposed action: Throw deprecation notice if error handler has five or more arguments. Otherwise, do not pass the ''$errcontext''. This prevents circumvention with ''func_get_args()''. |
| |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |
| * Second argument to ''spl_autoload''. | * Second argument to ''spl_autoload''. |
| * The ticks mechanism, which is obsoleted by async signal handling. | * The ticks mechanism, which is obsoleted by async signal handling. |
| * ''assert'' with string argument. | |
| |
| ===== Rejected deprecations ===== | ===== Rejected deprecations ===== |