#12286 [Bgs->Csd]: xml_parse isn't returning FALSE with malformed <?xml ...?> element

From: Date: Wed, 21 Aug 2002 15:08:37 +0000
Subject: #12286 [Bgs->Csd]: xml_parse isn't returning FALSE with malformed <?xml ...?> element
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-17447@lists.php.net to get a copy of this message
 ID:               12286
 User updated by:  jacek.prucia@7bulls.com
 Reported By:      jacek.prucia@7bulls.com
-Status:           Bogus
+Status:           Closed
 Bug Type:         XML related
 Operating System: Debian Potato 2.2 (Linux 2.2.17)
 PHP Version:      4.0.6
 New Comment:

Sorry for clutering PHP bug DB with this problem. After all, it turned
out that I didn't note the difference how feof() is returned with
fgets(). Because of that feof($file) wasn't evaluated to true, and
xml_parse was quiet, because it was sure that there are more XML blocks
pending. Thanks for response and clarification. I think i'll post this
story as a user comment to xml_parse function.


Previous Comments:
------------------------------------------------------------------------

[2002-08-19 10:51:52] chregu@php.net

Hi again

Of course, the script "works" (reports an error) if you change the xml
to

$xml = "<?xml version='dd'><root/>";

(that's what i wanted to say)

chregu

------------------------------------------------------------------------

[2002-08-19 10:50:29] chregu@php.net

hi

you have to call xml_parse with the third argument is_final set to
true, when you parse the last part of your xml-document. Then it shows
the error.

The following script works  fine for me:

<?php
$xml = "<?xml version='dd'?><root/>";

$xml_parser = xml_parser_create();
if (!xml_parse($xml_parser, $xml,1)) {
    printf("XML error: %s at line %d\n%d",
           xml_error_string(xml_get_error_code($xml_parser)),
           xml_get_current_line_number($xml_parser),
           xml_get_current_column_number($xml_parser));
    die();

}

?>

chregu






------------------------------------------------------------------------

[2002-08-19 09:02:26] jacek.prucia@7bulls.com

just tried expat 1.95.4 (latest from http://expat.sf.net) with:

1. standalone program (expat's outline.c example)
2. php4-STABLE-200208190000 (snaps.php.net) with Apache 1.3.26 compiled
with external expat support (--with-expat-dir=/usr) against that fresh
1.95.4

with 1 everything is just fine, parser catches error and displays:

Parse error at line 1:
unclosed token

However i still get the same result with 2, even when manipulating PHP
code a bit. In particular -- i have registerd a small function with
xml_set_processing_instruction_handler, that just echoes $target and
$data to stdout. Same effect -- no error from xml_parse

This might be a bit of help -- when I make an ordinary error (with
normal tag, not PI) parser catches that out and returns error.
Behaviour described in this bug only applies to xml PI tags.

I had a quick look at ext/xml/xml.c, but i'm not that familiar with PHP
 API yet, to be of any help ;)

------------------------------------------------------------------------

[2002-08-17 03:17:23] chregu@php.net

xml_parse has nothing to do with libxml, it uses the expat library.
Just as a clarification :)

chregu

------------------------------------------------------------------------

[2002-08-17 02:06:55] kalowsky@php.net

this actually sounds more like a problem with the library than the PHP
code.  Have you tried a recent version of the libxml to see if this
still continues?  While you're at it, do try a newer version of PHP
too, although I don't believe the xml extension has changed much. 

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/12286

-- 
Edit this bug report at http://bugs.php.net/?id=12286&edit=1



Thread (1 message)

  • jacek dot prucia at 7bulls dot com
  • Unknown Message
    • jacek dot prucia at 7bulls dot com
« previous php.bugs (#17447) next »