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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: zoeslam at gmail dot com
New email:
PHP Version: OS:

 

 [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 17:01:34 2024 UTC