php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67572 SimpleXMLElement not parsing \n correctly (???)
Submitted: 2014-07-04 13:10 UTC Modified: 2015-05-27 17:52 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: ondrej@php.net Assigned: cmb (profile)
Status: Duplicate Package: SimpleXML related
PHP Version: 5.6.0RC2 OS: any
Private report: No CVE-ID: None
 [2014-07-04 13:10 UTC] ondrej@php.net
Description:
------------
As reported here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729476

Original report is for 5.4.x (Debian wheezy).

--begin--
The documented behaviour of the empty() function is to be a shorthand
for "!isset($var) || var == false".  The below example shows a case
where this fails, and was triggering a subtle bug in my code after
upgrade of production server to Wheezy.  I think this may well affect
others and even be a security issue if "empty" variables are assumed to
be safe.

I noticed the issue running PHP under Apache but for simplicity the below
example can just be run on the command line.  I've not tested on any
later PHP version, sorry.
--end--

I have retested this on 5.6.0RC2.

And what's even more strange, that if I add var_dump($value) to the last loop, I will get:

---cut here--
object(SimpleXMLElement)#5 (0) {
}
---cut here--

even though dereferencing $value returns 'somevalue' correctly.

Test script:
---------------
<?php
$foo = 'bar';
print "regular string ... ";
var_dump(empty($foo)); #Should be false

$xml = simplexml_load_string("<xml><something>somevalue</something></xml>");
$xml2 = simplexml_load_string("<xml>\n<something>somevalue</something>\n</xml>");

foreach($xml as $key => $value) {
    print "$key = $value ... ";
    var_dump(empty($value)); # Should be false
    var_dump($value == false); # Should be false
}

foreach($xml2 as $key => $value) {
    print "$key = $value ... ";
    var_dump(empty($value)); # Should be false, but isn't
    var_dump($value == false); # Should be false
}
?>


Expected result:
----------------
regular string ... bool(false)
something = somevalue ... bool(false)
bool(false)
something = somevalue ... bool(false)
bool(false)

Actual result:
--------------
regular string ... bool(false)
something = somevalue ... bool(false)
bool(false)
something = somevalue ... bool(true)
bool(false)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-07-08 04:46 UTC] yohgaki@php.net
-Operating System: Debian (but probably any) +Operating System: any
 [2014-07-08 04:46 UTC] yohgaki@php.net
http://3v4l.org/7vXEg

It seems it's broken since 5.4.0.
 [2014-07-08 05:42 UTC] yohgaki@php.net
-Status: Open +Status: Verified
 [2014-08-08 16:10 UTC] csuffin at gracenote dot com
I have a work-around, of sorts.  I hope someone is investigating this bug because it is pretty awful.

I do not know how to solve the foreach() loop presented in ondrej's post, but if you're accessing elements individually, it seems that leaving off the "[0]" subscript works.  Don't ask me why!  See the test case below.  If you run this test with the assignment from "A" rather than "A[0]", it works.

<?php


function testfunc($str){

        echo "Testing on \"$str\"\n";

        $xml = new SimpleXMLElement($str);

        $a = $xml->A[0];
        //$a = $xml->A;
        echo "$a";
        if ($a) {
                $result = 1;
        } else {
                $result = 0;
        }

        echo " $result \n\n";

        return $result;
}



$r1 = testfunc ("<head><A>hello</A></head>");
$r2 = testfunc ("<head><A>first</A><A>hello</A> </head>");

if ($r1 && !$r2)
        echo " Test fails: white space makes 'A' element disappear! \n";
 [2015-05-27 17:52 UTC] cmb@php.net
-Status: Verified +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2015-05-27 17:52 UTC] cmb@php.net
After further investigation it turned out that this is a duplicate
of bug #66084.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC