php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #73925 BC break on array overriding declared string
Submitted: 2017-01-13 14:06 UTC Modified: 2017-10-24 16:45 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: zoeslam at gmail dot com Assigned:
Status: Open Package: Scripting Engine problem
PHP Version: 7.1.0 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2017-01-13 14:06 UTC] zoeslam at gmail dot com 
Description:
------------
PHP 7.1.0 changed a behaviour that was there from ages: array access overriding a previously declared string.

https://3v4l.org/25AIu

As far as I can read the docs, this change is a BC break and is NOT listed in the upgrading guide:
https://secure.php.net/manual/en/migration71.other-changes.php
Even though is similar to the "Notices and warnings on arithmetic with invalid strings" change.

Test script:
---------------
$string = '';
$string[0] = array(1);

var_dump($string);

Expected result:
----------------
array(1) {
  [0]=>
  array(1) {
    [0]=>
    int(1)
  }
}

Actual result:
--------------
Notice: Array to string conversion in /in/25AIu on line 4
string(1) "A"

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-13 14:14 UTC] zoeslam at gmail dot com 
Maybe more linked to https://secure.php.net/manual/en/migration71.incompatible.php#migration71.incompatible.empty-string-index-operator but still an undocumented BC break to me
 [2017-01-13 14:28 UTC] nikic@php.net
-Type: Bug +Type: Documentation Problem
 [2017-01-13 14:28 UTC] nikic@php.net 
Correct. The linked section currently only refers to the []= operation, while the same also applies to any [X]=.
 [2017-01-13 15:02 UTC] zoeslam at gmail dot com 
Ok, but the doc talk about a fatal error, here instead there is only an E_NOTICE, a huge difference.

May we uniform the behaviour to always raise a fatal error?
 [2017-01-13 18:39 UTC] cmb@php.net
-Status: Open +Status: Verified -Package: *General Issues +Package: Scripting Engine problem -Assigned To: +Assigned To: cmb
 [2017-01-13 18:39 UTC] cmb@php.net 
> Ok, but the doc talk about a fatal error, here instead there is
> only an E_NOTICE, a huge difference.

Indeed, and that has to be documented in the PHP manual and also
in UPGRADING.

> May we uniform the behaviour to always raise a fatal error?

I don't think that would make sense, but feel free to start the
RFC process, see <https://wiki.php.net/rfc/howto>. :-)
 [2017-01-14 10:52 UTC] zoeslam at gmail dot com 
I think that consistency is important, and the fact that the variable ends in a weird state (string "A") is very misleading. In the next days I'm going to write an RFC, and I hoe it could be merged in 7.1
 [2017-01-14 10:53 UTC] zoeslam at gmail dot com 
*hope
 [2017-10-24 05:26 UTC] kalle@php.net
-Status: Verified +Status: Assigned
 [2017-10-24 16:45 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Nov 26 15:01:37 2024 UTC