php[tek] 2018 : Call for Speakers

Other changes

Notices and warnings on arithmetic with invalid strings

New E_WARNING and E_NOTICE errors have been introduced when invalid strings are coerced using operators expecting numbers (+ - * / ** % << >> | & ^) or their assignment equivalents. An E_NOTICE is emitted when the string begins with a numeric value but contains trailing non-numeric characters, and an E_WARNING is emitted when the string does not contain a numeric value.

<?php
'1b' 'something';

L'exemple ci-dessus va afficher :

Notice: A non well formed numeric value encountered in %s on line %d
Warning: A non-numeric value encountered in %s on line %d

Warn on octal escape sequence overflow

Previously, 3-octet octal string escape sequences would overflow silently. Now, they will still overflow, but E_WARNING will be emitted.

<?php
var_dump
("\500");

L'exemple ci-dessus va afficher :

Warning: Octal escape sequence overflow \500 is greater than \377 in %s on line %d
string(1) "@"

Inconsistency fixes to $this

Whilst $this is considered a special variable in PHP, it lacked proper checks to ensure it wasn't used as a variable name or reassigned. This has now been rectified to ensure that $this cannot be a user-defined variable, reassigned to a different value, or be globalised.

Session ID generation without hashing

Session IDs will no longer be hashed upon generation. With this change brings about the removal of the following four ini settings:

  • session.entropy_file
  • session.entropy_length
  • session.hash_function
  • session.hash_bits_per_character

And the addition of the following two ini settings:

  • session.sid_length - defines the length of the session ID, defaulting to 32 characters for backwards compatibility)
  • session.sid_bits_per_character - defines the number of bits to be stored per character (i.e. increases the range of characters that can be used in the session ID), defaulting to 4 for backwards compatibility

Changes to INI file handling

precision

If the value is set to -1, then the dtoa mode 0 is used. The default value is still 14.

serialize_precision

If the value is set to -1, then the dtoa mode 0 is used. The value -1 is now used by default.

gd.jpeg_ignore_warning

The default of this php.ini setting has been changed to 1, so by default libjpeg warnings are ignored.

opcache.enable_cli

The default of this php.ini setting has been changed to 1 (enabled) in PHP 7.1.2.

Session ID generation with a CSPRNG only

Session IDs will now only be generated with a CSPRNG.

More informative TypeError messages when NULL is allowed

TypeError exceptions for arg_info type checks will now provide more informative error messages. If the parameter type or return type accepts NULL (by either having a default value of NULL or being a nullable type), then the error message will now mention this with a message of "must be ... or null" or "must ... or be null."

add a note add a note

User Contributed Notes 3 notes

up
12
ksours at internbrands dot com
11 months ago
It isn't documented anywhere that I can find, but there is another change to the string warnings in php7.1

$x = "";
$x['foo'] = 'bar';

Will quietly convert $x to an array in php70.  In php71 it will emit a warning and set the first character of $x to 'b' (roughly interpreting the line as $x[0] = 'b';)
up
1
tuxedobob
1 month ago
I'm sure this is something that some people think is the greatest thing ever, but to me, the warnings thrown by "bad" string to number conversion are a complete pain in the ass.

Plenty of code relies on the idea that 7 + '' = 7, no warning thrown, because that's expected.

I don't want to disable all warnings, just this one, but I can't, so now there's going to be

$total += (is_numeric($val) ? $val : 0);

all over the place.
up
0
mikey1974 at gmail DOT com
13 days ago
The idea behind throwing warnings in arithmethics is good (3 + "dogs" is useless), but in RFC was forgotten special case which causes a lot of pain ever since PHP 7.1 - arithmethics with 1. empty strings and 2. NULLs. These should NOT emit warnings and should be silently converted in non-strict mode. This is how PHP worked ever for years. Emiting warnings on empty strings and NULLs would be however OK in strictly typed mode. It's particularly this commit, which should be fixed: https://github.com/php/php-src/commit/1e82ad8038d3100b7e27be870652c1f639a7200a .
To Top