php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79528 Different object of the same xml between 7.4.5 and 7.4.4
Submitted: 2020-04-27 07:38 UTC Modified: 2020-05-05 16:01 UTC
From: roke22 at gmail dot com Assigned: cmb (profile)
Status: Closed Package: SimpleXML related
PHP Version: 7.4.5 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: roke22 at gmail dot com
New email:
PHP Version: OS:

 

 [2020-04-27 07:38 UTC] roke22 at gmail dot com
Description:
------------
---
From manual page: https://php.net/function.simplexml-load-string
---

We got different object when we read the same xml with php 7.4.4 and 7.4.5.

In php 7.4.4 we got a SimpleXMLElement object with an array.
In php 7.4.5 we got a SimpleXMLElement object with SimpleXMLElement objects.

This cause different behaviour on the same code. I think that in minor changes this have to be the same result.

Test script:
---------------
<?php
$resultado = simplexml_load_string("<value1><value2><value3 valueinside='1'>17321</value3><value3 valueinside='2'>17321</value3></value2></value1>");
var_dump($resultado);

Expected result:
----------------
We expect the same resulto on both versions.

Actual result:
--------------
root@400e641ac608:/# php --version
PHP 7.4.5 (cli) (built: Apr 17 2020 11:29:12) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v2.9.4, Copyright (c) 2002-2020, by Derick Rethans
root@400e641ac608:/# cd /var/www/html/
root@400e641ac608:/var/www/html# php prueba.php 
/var/www/html/prueba.php:3:
class SimpleXMLElement#1 (1) {
  public $value2 =>
  class SimpleXMLElement#2 (1) {
    public $value3 =>
    array(2) {
      [0] =>
      class SimpleXMLElement#3 (2) {
        ...
      }
      [1] =>
      class SimpleXMLElement#4 (2) {
        ...
      }
    }
  }
}


root@757c3e5e6b91:/var/www/html# php --version
PHP 7.4.4 (cli) (built: Apr 16 2020 15:22:19) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v2.9.4, Copyright (c) 2002-2020, by Derick Rethans
root@757c3e5e6b91:/var/www/html# php prueba.php 
/var/www/html/prueba.php:3:
class SimpleXMLElement#1 (1) {
  public $value2 =>
  class SimpleXMLElement#2 (1) {
    public $value3 =>
    array(2) {
      [0] =>
      string(5) "17321"
      [1] =>
      string(5) "17321"
    }
  }
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-04-27 07:48 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2020-04-27 07:48 UTC] requinix@php.net
The change in behavior is a result of a bug fix - see bug #61597.

The problem was that nodes with attributes were being treated as strings in cases that they should not have been. Your example is one such case: the <value3> elements have attributes so simply treating them as strings would lose that data.
 [2020-04-27 07:53 UTC] nikic@php.net
To be clear, this should have changed only debug output, not anything else.
 [2020-04-30 21:55 UTC] ttijhof at wikimedia dot org
This changed has caused observable changes in user-land code in a bug release, which seems like something that should not happen.

An isolated test case exists at https://3v4l.org/HtN9R.

This is not debugging output, these are run-time return values. And it doesn't even rely on reflection or something hacky like that.

I would expect a breaking change of this kind, where the API provides an entirely different return value (string vs array of objects), to be something that happens in a major release like PHP 8.0, not in a minor release, and most definitely not in a patch release to PHP 7.3 or PHP 7.4. Even then I would think such change, which is hard to support both versions of, would probably benefit from a feature flag, run-time option, or some other method name so that there is a deprecation notice and so that one can actually do a running migration.
 [2020-04-30 22:20 UTC] nikic@php.net
-Status: Not a bug +Status: Re-Opened -Assigned To: +Assigned To: cmb
 [2020-04-30 22:20 UTC] nikic@php.net
@cmb: Looks like this had some unintended effects.
 [2020-05-01 10:14 UTC] cmb@php.net
In hindsight, I agree that this should not have been changed in
revision releases, so I'm going to revert, and also check with the
release managers whether the revert can be applied to PHP 7.3.18
and 7.4.6.

Furthermore, the new behavior still doesn't make sense[1], so
perhaps sticking with the old behavior even for PHP 8 might be
best. 

[1] <https://3v4l.org/SPp3f>
 [2020-05-01 10:43 UTC] cmb@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=54148fd68677e8b13b5a11c309c601d1248fb78b
Log: Fix #79528: Different object of the same xml between 7.4.5 and 7.4.4
 [2020-05-01 10:43 UTC] cmb@php.net
-Status: Re-Opened +Status: Closed
 [2020-05-01 11:21 UTC] cmb@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=cb265a0addf15c5cf0c029f167a9de030150cf15
Log: Fix #79528: Different object of the same xml between 7.4.5 and 7.4.4
 [2020-05-05 15:50 UTC] php at kriegt dot es
So this will be reverted in 7.4.6 and 7.3.18, right?
 [2020-05-05 16:01 UTC] cmb@php.net
Yes, the revert of the fix for bug #61597 will be in PHP 7.3.18 and 7.4.6.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 03:01:27 2024 UTC