Bug #49104 [Com]: AppendIterator::append($iterator) calls $iterator-rewind() with no reason
Edit report at https://bugs.php.net/bug.php?id=49104edit=1
ID: 49104
Comment by: hanskrentel at yahoo dot de
Reported by:seva dot lapsha at gmail dot com
Summary:AppendIterator::append($iterator) calls
$iterator-rewind() with no reason
Status: Assigned
Type: Bug
Package:SPL related
Operating System: *
PHP Version:5.3.0
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
AppendIterator just takes care that the internal iterator state is at a
validated position of at least one iterator. This perhaps is not necessary at
all, but it *might* be needed to take care of internal iterator states as PHP
shares a lot of code across iterators (as this ticket didn't get much traction
nor feedback from core developers, I'd say in summary nobody wants to fiddle
with that). In the end AppendIterator is still an IteratorIterator and those
have this internal state:
Compare: Why must I rewind IteratorIterator -
http://stackoverflow.com/q/2458955/367456
In code: http://lxr.php.net/xref/PHP_5_4/ext/spl/spl_iterators.c#3347
If rewind on appending is an issue - and despite / in contrast to what has been
outlined as workaround already - if those safety checks PHP does are not
wanted,
you can take care your own by adding the iterators directly to the internal
collection of iterators:
?php
$i1 = new ArrayIterator1(array(1, 2, 3));
$i2 = new ArrayIterator1(array(4, 5, 6));
$append = new AppendIterator();
/* @var $i ArrayIterator */
$i = $append-getArrayIterator();
$i-append($i1);
$i-append($i2);
Some notes:
- You can append anything here, no type-check is enforced. However everything
not a Traversable will crash the script on iteration when reached (e.g. exit
code -1073741819). This has the benefit that unlike ArrayIterator::append() you
*can* add Traversable (e.g. IteratorAggregate) and not only Iterator. This also
works for Traversable only classes like DatePeriod.
- This still does work while iterating (as it does for
AppendIterator::append()).
- ArrayAccess can be used, too: $i[] = $i1;
I hope this helps someone running into the issue in PHP user land.
Previous Comments:
[2011-03-23 18:32:46] demjan at kaluzki dot de
The rewind is invoked only on the first appended (not empty) inner-iterator.
workaround:
$workaround = new
ArrayIterator(array('delete_me_after_all_append_calls_are_done'));
$a = new ArrayIterator(array('a', 'b'));
$b = new ArrayIterator(array('c', 'd'));
$append = new AppendIterator();
$append-append($workaround); // invokes implicit:
// $workaround-rewind();
// $workaround-valid();
// $workaround-current();
// $workaround-key();
// $workaround-rewind();
$append-append($a);
$append-append($b);
unset($workaround[0]); // no further append calls are allowed,
// otherwise it seems to hang up in infinite loop
[2009-07-29 22:57:40] seva dot lapsha at gmail dot com
Line 6:
x This causes append to happen twice:
should be read as
* This causes rewind to happen twice:)
[2009-07-29 22:54:19] seva dot lapsha at gmail dot com
Description:
AppendIterator::append($iterator) calls $iterator-rewind() with no reason.
This causes append to happen twice:
1) when $iterator appended;
2) when $iterator starts iterating.
Reproduce code:
---
?php
class ArrayIterator1 extends ArrayIterator {
function rewind() {
echo .;
parent::rewind();
}
}
$i1 = new ArrayIterator1(array(1, 2, 3));
$i2 = new ArrayIterator1(array(4, 5, 6));
$i = new AppendIterator();
$i-append($i1);
$i-append($i2);
foreach ($i as $n) {
echo $n;
}
?
Expected result:
.123.456
rewind() of each append()ed iterator should be called on demand when iterating
and not when append()ing.
Actual result:
--
..123.456
On each append() each append()ed iterator's rewind is called with no need.
--
Edit this bug report at https://bugs.php.net/bug.php?id=49104edit=1
Bug #64931 [Com]: phar_add_file is too restrive on filename
Edit report at https://bugs.php.net/bug.php?id=64931edit=1 ID: 64931 Comment by: hanskrentel at yahoo dot de Reported by:william dot martin at power-lan dot com Summary:phar_add_file is too restrive on filename Status: Open Type: Bug Package:PHAR related Operating System: Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: According to the code, the error message is different to what the code does: http://lxr.php.net/xref/PHP_5_4/ext/phar/phar_object.c#3708 The code checks if the filename starts with .phar. The message says there would be a .phar directory (and that one is magic). I don't know what is magic about .phar. I guess the error message is not lying and it's about directory. And indeed one can find some more references to that string containing files like: .phar/stub.php .phar/alias.txt A more proper check would probably to check for the sole string .phar (fixed length) or .phar/ (for the start). There are multiple places where the check is not done that consequently, for example as well in http://lxr.php.net/xref/PHP_5_4/ext/phar/phar_object.c#3825 Taking the knowledge from those settings reveals the feature to create such files: ?php touch(.pharignore); $phar = new \Phar(foo.phar, 0, foo.phar); $phar-addFile(.pharignore, /.pharignore); ? This code creates the file .pharignore inside. It's also possible to add files inside the magic .phar folder for wich I'll create a new ticket. Previous Comments: [2013-05-27 15:43:35] william dot martin at power-lan dot com Description: The function phar_add_file start by test if we try to write something in the .phar magic directory, but the test is in really : Does a filepath start by .phar ? So if you try to pack files likes .pharignore, php throw an exception: Error: Cannot create any files in magic .phar directory. Test script: --- ?php touch(.pharignore); $phar = new \Phar(foo.phar, 0, foo.phar); $phar-addFile(.pharignore, .pharignore); -- Edit this bug report at https://bugs.php.net/bug.php?id=64931edit=1
Bug #64931 [Com]: phar_add_file is too restrive on filename
Edit report at https://bugs.php.net/bug.php?id=64931edit=1 ID: 64931 Comment by: hanskrentel at yahoo dot de Reported by:william dot martin at power-lan dot com Summary:phar_add_file is too restrive on filename Status: Open Type: Bug Package:PHAR related Operating System: Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: The related bug is: Sec Bug #65414 Previous Comments: [2013-08-07 10:54:51] hanskrentel at yahoo dot de According to the code, the error message is different to what the code does: http://lxr.php.net/xref/PHP_5_4/ext/phar/phar_object.c#3708 The code checks if the filename starts with .phar. The message says there would be a .phar directory (and that one is magic). I don't know what is magic about .phar. I guess the error message is not lying and it's about directory. And indeed one can find some more references to that string containing files like: .phar/stub.php .phar/alias.txt A more proper check would probably to check for the sole string .phar (fixed length) or .phar/ (for the start). There are multiple places where the check is not done that consequently, for example as well in http://lxr.php.net/xref/PHP_5_4/ext/phar/phar_object.c#3825 Taking the knowledge from those settings reveals the feature to create such files: ?php touch(.pharignore); $phar = new \Phar(foo.phar, 0, foo.phar); $phar-addFile(.pharignore, /.pharignore); ? This code creates the file .pharignore inside. It's also possible to add files inside the magic .phar folder for wich I'll create a new ticket. [2013-05-27 15:43:35] william dot martin at power-lan dot com Description: The function phar_add_file start by test if we try to write something in the .phar magic directory, but the test is in really : Does a filepath start by .phar ? So if you try to pack files likes .pharignore, php throw an exception: Error: Cannot create any files in magic .phar directory. Test script: --- ?php touch(.pharignore); $phar = new \Phar(foo.phar, 0, foo.phar); $phar-addFile(.pharignore, .pharignore); -- Edit this bug report at https://bugs.php.net/bug.php?id=64931edit=1
Bug #44367 [Com]: DOMDocument::baseURI parsing is out of whack
Edit report at https://bugs.php.net/bug.php?id=44367edit=1
ID: 44367
Comment by: hanskrentel at yahoo dot de
Reported by:daniel dot oconnor at gmail dot com
Summary:DOMDocument::baseURI parsing is out of whack
Status: Not a bug
Type: Bug
Package:DOM XML related
Operating System: Windows
PHP Version:5.2.5
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Please take care that PHP's DOMDocument does not offer the DOM CORE Level 3
feature at all. So whatever the specs of that DOM Core Level say, nothing -
absolutely nothing - allows to draw the conclusion that this (perhaps by
accident
same named property) is an implementation of DOM Core Level 3.
PHP's DOMDocument has only DOM Core Level 1 feature which does not cover this
property.
All references to XML Infoset in this ticket are therefore completely bogus.
Previous Comments:
[2013-02-15 09:52:26] sites at hubmed dot org
A test case which illustrates that the baseURI parsing is working correctly now
(at least in PHP 5.3.15):
?php
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI); //
http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml;
var_dump($doc-documentElement-baseURI); // http://.example.org/;
As http://www.w3.org/TR/xmlbase/ describes, the base URI of a document entity
is the URI used to retrieve the document entity. The base URI of an element
(including the document element) is
detected by various rules, starting with the xml:base attribute on the element.
[2008-03-12 22:30:13] daniel dot oconnor at gmail dot com
:S I hate being pushy / argumentitive, sorry if its coming across that way.
RFC 2396 is Uniform Resource Identifiers (URI): Generic Syntax
Section 5.1. is Establishing a Base URI describes what I've been trying to
say, probably a little clearer.
XML Base spec @ http://www.w3.org/TR/xmlbase/#rfc2396 says:
Determine a baseURI:
1. The base URI is embedded in the document's content.
2. The base URI is that of the encapsulating entity (message, document, or
none).
3. The base URI is the URI used to retrieve the entity.
4. The base URI is defined by the context of the application.
This is not just how it is implemented in PHP as the other major DOM parsers
implement it the same way
... and that's why the xml:base GRDDL tests were written - to clarify correct
behaviour / check implementations.
[2008-03-12 17:16:05] rricha...@php.net
still bogus as what you are describing pertains to GRDDL only not DOM,
so when working with GRDDL and DOm you need to check base uri of the
document element, not the DOMDocument.
DOM determines base uri using the xml base spec.
The base URI of a document entity or an external entity is determined
by RFC 2396 rules, namely, that the base URI is the URI used to retrieve
the document entity or external entity.
This is not just how it is implemented in PHP as the other major DOM
parsers implement it the same way,
[2008-03-11 00:03:46] daniel dot oconnor at gmail dot com
See http://www.w3.org/TR/grddl/#base_misc
http://www.apps.ietf.org/rfc/rfc3986.html#sec-5.1
The way to determine baseURI is:
1. Look for it on the root document element (HTML - base, XML - foo
xml:base=
2. Couldn't find that? Use the URL we retrieved the document with
* And make sure we follow redirects!
3. Couldn't find that? Application specific (but we don't really have a
setBaseURI())
So, condition #1 is broken in 5.2.5 when you do:
?php
$doc =
DOMDocument::load('http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml');
var_dump($doc-baseURI);//Expected http://.example.org/
produces:
string(53) http://www.w3.org/2001/sw/grddl-wg/td/inline-rdf6.xml;
[2008-03-10 14:09:30] rricha...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Don't know about GRDDL, but for DOM trees, base uri of a DOMDocument is
the URI its loaded from (or for memory based tree, the current dir).
You need to check on the document element to get the base uri you are
looking for.
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
https://bugs.php.net/bug.php?id=44367
--
Edit this bug report
Bug #60873 [Com]: some inspections of DateTime member variables cause creation, can break asserts
Edit report at https://bugs.php.net/bug.php?id=60873edit=1
ID: 60873
Comment by: hanskrentel at yahoo dot de
Reported by:kavi at postpro dot net
Summary:some inspections of DateTime member variables cause
creation, can break asserts
Status: Open
Type: Bug
Package:Date/time related
Operating System: n/a
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
DateTime objects have a timezone_type member variable.
This must be a non-permanent member (aka a variable property like any
PHP object offers if you set those).
The PHP documentation fosters this assumptions because for DateTime no
public properties are documented. So none are defined. If you enable
error reporting to the highest level in your example, I bet PHP
complains about undefined properties (which are non-fatal).
As you have reported this as a bug:
Please outline why you expect DateTime having some defined
(non-variable) properties when those aren't given for the class reflection?
Reflection shows you can't expect those members to be defined by default:
https://eval.in/private/2760b020207190
Class [ internal:date class DateTime ] {
...
- Static properties [0] {
}
...
Previous Comments:
[2012-01-24 22:19:26] kavi at postpro dot net
Description:
DateTime objects have a timezone_type member variable. This appears to differ
based on whether the timezone was set by passing a DateTimeZone object to the
DateTime constructor vs the constructor parsing it out of a string. The
timezone_type member variable is not mentioned anywhere in the documentation,
nor
is this behavior.
Further, inspecting DateTime objects with print_r and other interrogations can
cause the timezone_type properties to be created. Equality operator
comparisons
still work when timezone_type properties created and are different, but isEqual
in
SimpleTest (for example) does not, nor presumably will other object comparisons
which don't use what I imagine to be DateTime's overloaded comparison operators.
Please document the timezone_type member variable of DateTime and address the
unexpected behavior of member variable creation upon inspection.
Test script:
---
?php
$a = new DateTime('2010-01-01 08:45:00', new DateTimeZone('UTC'));
$str = $a-format(DateTime::ISO8601);
$b = new DateTime($str, new DateTimeZone('UTC'));
echo \n;
echo a-timezone_type: . $a-timezone_type . \n;
echo b-timezone_type: . $b-timezone_type . \n;
echo \na:. print_r($a, true) . \n;
echo \nstr: $str\n;
echo b:. print_r($b, true) . \n;
echo a-timezone_type: . $a-timezone_type . \n;
echo b-timezone_type: . $b-timezone_type . \n;
$eq = ($a == $b);
echo \na == b: $eq\n;
Expected result:
$ php test.php
a-timezone_type: 3
b-timezone_type: 1
a: DateTime Object
(
[date] = 2010-01-01 08:45:00
[timezone_type] = 3
[timezone] = UTC
)
str: 2010-01-01T08:45:00+
b: DateTime Object
(
[date] = 2010-01-01 08:45:00
[timezone_type] = 1
[timezone] = +00:00
)
a-timezone_type: 3
b-timezone_type: 1
a == b: 1
Actual result:
--
$ php test.php
a-timezone_type:
b-timezone_type:
a: DateTime Object
(
[date] = 2010-01-01 08:45:00
[timezone_type] = 3
[timezone] = UTC
)
str: 2010-01-01T08:45:00+
b: DateTime Object
(
[date] = 2010-01-01 08:45:00
[timezone_type] = 1
[timezone] = +00:00
)
a-timezone_type: 3
b-timezone_type: 1
a == b: 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60873edit=1
Bug #49382 [Com]: can't access DateTime-date
Edit report at https://bugs.php.net/bug.php?id=49382edit=1
ID: 49382
Comment by: hanskrentel at yahoo dot de
Reported by:klawd at kamundo dot de
Summary:can't access DateTime-date
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Debian GNU/Linux 5.0
PHP Version:5.3.0
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I wonder how this qualifies as a bug as any object can have variable properties
and accessing undefined ones give notices.
Just sounds like standard PHP behavior here.
Previous Comments:
[2012-12-29 17:56:02] info at metashock dot net
I think it is interesting that the property can be accessed using reflection.
Using the following example I can access the property:
$dt = new DateTime();
$o = new ReflectionObject($dt);
$p = $o-getProperty('date');
$date = $p-getValue($dt)); // returns the value of DateTime::$date
[2010-08-04 22:36:58] weirdan at gmail dot com
if this was not intended to work this way, why won't you just fix it so that no
properties are created as a result of print_r / Reflection::export() /
foreach() /
property_exist / array cast?
[2010-03-07 20:22:06] der...@php.net
-date being available is actually a side-effect of support for var_dump()
here. I'll mark this as a feature request as it was not intended to work.
[2009-08-27 07:52:37] klawd at kamundo dot de
Description:
Can not access property date of DateTime.
Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt-date;
gets me Notice: Undefined property: DateTime::$date
strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt-date;
DateTime Object ( [date] = 1742-05-23 00:00:00 [timezone_type] = 3 [timezone]
= UTC ) 1742-05-23 00:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=49382edit=1
Bug #60873 [Com]: some inspections of DateTime member variables cause creation, can break asserts
Edit report at https://bugs.php.net/bug.php?id=60873edit=1
ID: 60873
Comment by: hanskrentel at yahoo dot de
Reported by:kavi at postpro dot net
Summary:some inspections of DateTime member variables cause
creation, can break asserts
Status: Open
Type: Bug
Package:Date/time related
Operating System: n/a
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Because the current behavior doesn't make sense, and the expected behavior
does.
So are you trying to sell me a self-fulfilling prophecy as an argument?
Furthermore [...] the actual bug is that DateTime objects behave differently
in some situations
That statement is wrong. If you treat the DateTimne objects the same, they
behave the same.
Still yet I can't see how that answers my previous question how one can expect
an undefined property to exist on an object as it's undefined.
And variable properties are in PHP since version 3. So if you find some
property
on an object you wonder about, first find out where the property originates
from. Is it a default one (term leaned from PHP ReflectionObject) or has it
been
added later (variable property). For the later ones, it must not have been
added
by the object itself so can as well be added by other code that has touched the
object from the outside.
In your example code print_r is adding those variable properties for example.
But I can easily write a function that adds those properties as well and this
would be completely bug-free PHP code.
Previous Comments:
[2013-07-09 19:08:43] kavi at postpro dot net
Furthermore, and with the benefit of further coffee consumption, the actual bug
is that DateTime objects behave differently in some situations depending upon
how they are created, even if the date, time, and time zone they represent are
identical.
[2013-07-09 13:42:30] kavi at postpro dot net
Please outline why you expect DateTime having some defined
(non-variable) properties when those aren't given for the class reflection?
Because the current behavior doesn't make sense, and the expected behavior does.
[2013-07-09 10:41:00] hanskrentel at yahoo dot de
DateTime objects have a timezone_type member variable.
This must be a non-permanent member (aka a variable property like any
PHP object offers if you set those).
The PHP documentation fosters this assumptions because for DateTime no
public properties are documented. So none are defined. If you enable
error reporting to the highest level in your example, I bet PHP
complains about undefined properties (which are non-fatal).
As you have reported this as a bug:
Please outline why you expect DateTime having some defined
(non-variable) properties when those aren't given for the class reflection?
Reflection shows you can't expect those members to be defined by default:
https://eval.in/private/2760b020207190
Class [ internal:date class DateTime ] {
...
- Static properties [0] {
}
...
[2012-01-24 22:19:26] kavi at postpro dot net
Description:
DateTime objects have a timezone_type member variable. This appears to differ
based on whether the timezone was set by passing a DateTimeZone object to the
DateTime constructor vs the constructor parsing it out of a string. The
timezone_type member variable is not mentioned anywhere in the documentation,
nor
is this behavior.
Further, inspecting DateTime objects with print_r and other interrogations can
cause the timezone_type properties to be created. Equality operator
comparisons
still work when timezone_type properties created and are different, but isEqual
in
SimpleTest (for example) does not, nor presumably will other object comparisons
which don't use what I imagine to be DateTime's overloaded comparison operators.
Please document the timezone_type member variable of DateTime and address the
unexpected behavior of member variable creation upon inspection.
Test script:
---
?php
$a = new DateTime('2010-01-01 08:45:00', new DateTimeZone('UTC'));
$str = $a-format(DateTime::ISO8601);
$b = new DateTime($str, new DateTimeZone('UTC'));
echo \n;
echo a-timezone_type: . $a-timezone_type . \n;
echo b-timezone_type: . $b-timezone_type . \n;
echo \na:. print_r($a, true) . \n;
echo \nstr: $str\n;
echo b:. print_r($b, true) . \n;
echo a-timezone_type: . $a-timezone_type . \n;
echo b-timezone_type: . $b-timezone_type . \n;
$eq = ($a == $b);
echo \na == b: $eq\n;
Expected result:
$ php test.php
a-timezone_type: 3
b-timezone_type: 1
a: DateTime Object
(
[date] = 2010
Bug #36795 [Com]: Inappropriate unterminated entity reference in DOMElement-setAttribute
Edit report at https://bugs.php.net/bug.php?id=36795edit=1 ID: 36795 Comment by: hanskrentel at yahoo dot de Reported by:john at carney dot id dot au Summary:Inappropriate unterminated entity reference in DOMElement-setAttribute Status: Not a bug Type: Bug Package:DOM XML related Operating System: * PHP Version:5.*, 6 Block user comment: N Private report: N New Comment: This is bogus because as character is needed in the attribute values to start an entity to express character references. Otherwise it would not be possible to set the superset of all XML attribute values (AttValue; http://www.w3.org/TR/xml/#NT- AttValue), the expression wouldn't be distinct. Like you need to write \t in a PHP string to express a tab and therefore \\ to express the slash. I hope this clarifies this a bit. Previous Comments: [2011-10-08 18:33:10] matteosistisette at gmail dot com I'm still observing this issue (by the way, why is it marked as bogus?). Even the simplexml property accessors does give me the warning, such as: $a['b'] = '; // GENERATES THE WARNING [2011-09-11 01:40:13] abxccd at msn dot com I am still seeing this bug in PHP 5.3.8 [2011-02-23 03:30:34] jan-bugreport at gmx dot de With simpleXML, addChild($name, $value) works really weird (tested on 5.3.1 on win): in the value, the characters and are correctly esacped to lt; and gt; but ampersands cause the unterminated entity reference message. I would understand if it escaped nothing, or if it escaped everything, but this seems weird. Also, no matter what the final decision about this bug will be, this should be documented really well in the SimpleXML docs. It is confusing and I could imagine it could cause security issues in some applications. [2010-09-22 01:02:27] steven at navolutions dot com I also had this issue, one thing that might not have been included in the original reproducing of the code is that the DOMElement may have been extended. I know mine is extended so Reproduce the code by extending the DOMElement class. I also extended the DOMDocuement class so try that too. So no the status is not Bogus, just to tested thoroughly. [2010-04-09 14:01:23] rricha...@php.net Behavior as defined by DOM specs. No warnings are issued are from either of the 2 examples in the reproduced code. addChild() method described in later reports works are defined by specs. Use the simplexml property accessors for auto escaping. 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 https://bugs.php.net/bug.php?id=36795 -- Edit this bug report at https://bugs.php.net/bug.php?id=36795edit=1
Req #38489 [Com]: DOMNodeList should implement Traversable
Edit report at https://bugs.php.net/bug.php?id=38489edit=1
ID: 38489
Comment by: hanskrentel at yahoo dot de
Reported by:mmcintyre at squiz dot net
Summary:DOMNodeList should implement Traversable
Status: Closed
Type: Feature/Change Request
Package:DOM XML related
Operating System: *
PHP Version:5.1.5
Assigned To:jpauli
Block user comment: N
Private report: N
New Comment:
iterator_to_array() accepts any terversable, therefore there is no need to wrap
the DOMNodeList into an IteratorIterator first, it can be converted to array
*directly*
?php
$xml = 'queriesquery attr1=value/query/queries';
$doc = new DOMDocument;
$doc-loadXML($xml);
$queries = $doc-getElementsByTagName('queries');
$nodes = iterator_to_array($queries);
?
The key used per each node is some kind of ID (positive, long integer) and it
seems to be unique. Using an array can be useful because a DOMNodeList
automatically re-orders if nodes therein are deleted. This is not the case with
the array (naturally).
Previous Comments:
[2012-01-10 16:42:53] jpa...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
DomNodeListe implements Traversable. You can convert a Traversable object to an
Iterator using the IteratorIterator
class.
?php
$xml = 'queriesquery attr1=value/query/queries';
$doc = new DOMDocument;
$doc-loadXML($xml);
$queries = $doc-getElementsByTagName('queries');
$nodes = iterator_to_array(new IteratorIterator($queries));
?
[2007-01-17 15:11:55] jules_papillon_fh at yahoo dot de
This bug exists further reproducibly on PHP5.2
[2007-01-17 15:09:11] jules_papillon_fh at yahoo dot de
Another Code to reproduce the Bug:
--
$dom = new DOMDocument('1.0', 'ISO-8859-1');
$dom-load('file.xml');
$iterator = new RecursiveIteratorIterator($dom-childNodes,
RecursiveIteratorIterator::SELF_FIRST);
foreach($iterator as $name = $element) {
print $name . \n;
}
Expected result:
A recursive List of all Elements
Actual result:
--
Catchable fatal error: Argument 1 passed to
RecursiveIteratorIterator::__construct() must implement interface Traversable,
instance of DOMNodeList given, called in [
] and defined in [
]
[2006-08-18 06:37:22] mmcintyre at squiz dot net
Description:
Currently, a DOMNodeList object can be traversed using a foreach loop, but it
cannot be converted to an array using iterator_to_array(), as it produces an
error Warning: iterator_to_array() expects parameter 1 to be Traversable,
object given
Reproduce code:
---
$xml = 'queriesquery attr1=value/query/queries';
$doc = new DOMDocument;
$doc-loadXML($xml);
$queries = $doc-getElementsByTagName('queries');
$nodes = iterator_to_array($queries);
Expected result:
The nodes in the NodeList are returned as an array.
Actual result:
--
Warning: iterator_to_array() expects parameter 1 to be Traversable, object
given
--
Edit this bug report at https://bugs.php.net/bug.php?id=38489edit=1
Bug #64870 [Com]: mysqlnd: can't connect to updated MySQL server with old_password Off
Edit report at https://bugs.php.net/bug.php?id=64870edit=1
ID: 64870
Comment by: hanskrentel at yahoo dot de
Reported by:marceloinxs at gmail dot com
Summary:mysqlnd: can't connect to updated MySQL server with
old_password Off
Status: Open
Type: Bug
Package:MySQLi related
Operating System: Windows 7 64bit
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
The weird thing is that the database is actually MySQL 5.5.24, old_password
variable is Off and passwords are actually 41 byte encoded.
You write variable here. The error message clearly directs you to the
configuration file (which is *not* a variable).
Please check your configuration file and report back which related settings
you've
got in there.
Previous Comments:
[2013-05-17 16:44:57] marceloinxs at gmail dot com
Description:
Windows 7 build 7601, Apache 2.2.24 (Win32). Upgraded PHP from 5.2.* to 5.4.15,
mysql_* and mysqli_* can't connect to any databases. Then downgraded to 5.3.25,
same result.
The error is always the same:
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]:
Premature end of data (mysqlnd_wireprotocol.c:553)
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]: OK
packet 1 bytes shorter than expected
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]:
(HY000/2000): mysqlnd cannot connect to MySQL 4.1+ using the old insecure
authentication. Please use an administration tool to reset your password with
the command SET PASSWORD = PASSWORD('your_existing_password'). This will store
a new, and more secure, hash value in mysql.user. If this user is used in other
scripts executed by PHP 5.2 or earlier you might need to remove the
old-passwords flag from your my.cnf file
The weird thing is that the database is actually MySQL 5.5.24, old_password
variable is Off and passwords are actually 41 byte encoded.
The database is remote, but remote connections are allowed. I even tried the
same script in Linux based server (PHP 5.4.10) and it worked.
Both mysql and mysqli extensions are correctly loaded in php.ini.
The main difference between PHP 5.2 and newer versions is that they now use
mysqlnd as driver. Maybe it is buggy in Windows?
You can have an extended look of this here:
http://stackoverflow.com/questions/16598572/mysqlnd-cannot-connect-to-mysql-5-5-24-old-password-is-off
Test script:
---
?php
$mysqli = new mysqli('aaa', 'bbb', 'ccc', 'ddd');
if($mysqli-connect_error) {
die( $mysqli-connect_error );
}
echo 'connected';
?
Expected result:
'connected'
Actual result:
--
Warning: mysqli::mysqli() [mysqli.mysqli]: Premature end of data
(mysqlnd_wireprotocol.c:553) in ... on line 3
Warning: mysqli::mysqli() [mysqli.mysqli]: OK packet 9 bytes shorter than
expected in ... on line 3
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2000): mysqlnd cannot connect
to MySQL 4.1+ using the old insecure authentication. Please use an
administration tool to reset your password with the command SET PASSWORD =
PASSWORD('your_existing_password'). This will store a new, and more secure,
hash value in mysql.user. If this user is used in other scripts executed by PHP
5.2 or earlier you might need to remove the old-passwords flag from your my.cnf
file in ... on line 3
mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication.
Please use an administration tool to reset your password with the command SET
PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more
secure, hash value in mysql.user. If this user is used in other scripts
executed by PHP 5.2 or earlier you might need to remove the old-passwords flag
from your my.cnf file
--
Edit this bug report at https://bugs.php.net/bug.php?id=64870edit=1
Bug #54290 [Com]: Class which extends from \SplFileObject is not serializable
Edit report at https://bugs.php.net/bug.php?id=54290edit=1
ID: 54290
Comment by: hanskrentel at yahoo dot de
Reported by:frederic dot hardy at mageekbox dot net
Summary:Class which extends from \SplFileObject is not
serializable
Status: Open
Type: Bug
Package:SPL related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
According to the code it is intended that you can not serialize it.
Which can make sense as the file itself already is a serialized form
of the object it represents. However different to DOMDocument where
serialization wouldn't make much sense (XML is a serialization
already), in the SplFileObject case, Serialization is *explicitly*
forbidden. The internal state of the object can not be preserved by
serialization, therefore it is just not possible.
This ticket can be closed as a duplicate of #46646 in my eyes or it
needs to be turned into a feature-request, so that implementing
Serializable might become possible - like it is with DOMDocument.
Previous Comments:
[2011-03-21 19:01:41] jinmoku at hotmail dot com
see bug :
http://bugs.php.net/bug.php?id=46646
http://svn.php.net/viewvc/php/php-src/trunk/ext/spl/spl_directory.c?r1=271751r2=271752
;)
[2011-03-17 11:04:21] frederic dot hardy at mageekbox dot net
Description:
It's impossible to implements \Serializable interface on a class which extends
from \SplFileObject.
Test script:
---
?php
namespace php\bugs\splFileObject;
class SerializableFileObject extends \SplFileObject implements \Serializable
{
public function serialize()
{
}
public function unserialize($serialized)
{
}
}
?
Expected result:
Nothing.
Actual result:
--
PHP Fatal error: Class php\bugs\splFileObject\Serializable could not implement
interface Serializable in Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=54290edit=1
[PHP-BUG] Req #64782 [NEW]: SplFileObject constructor make $context optional / give it a default value
From: hanskrentel at yahoo dot de
Operating system:
PHP version: 5.4.14
Package: SPL related
Bug Type: Feature/Change Request
Bug description:SplFileObject constructor make $context optional / give it a
default value
Description:
When extending from SplFileObject and overwriting the constructor, it is
not
easily possible to override the parent one because for the last parameter
$context
one can not provide an optional default.
Therefore it requires (somewhat needles) if-branched code only to deal with
the
$context not passed case when calling the parents constructor.
It would be nice if $context does accept NULL then if I do not want to use
any
context but need to specify the parameter.
Test script:
---
?php
class Myfile extends SplFileObject
{
public function __construct($file_name, $open_mode = r,
$use_include_path = FALSE, $context = NULL) {
$this-levels = new Levels();
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
$file = new MyFile(__FILE__);
Expected result:
It should not give any warning or error.
Actual result:
--
Warning: Missing argument 4 for Myfile::__construct(), called in [pointing
to the
line $file = new MyFile(__FILE__);] and defined in [pointing to the line
public function __construct($file_name, $open_mode = r,
$use_include_path =
FALSE, $context = NULL) {]
--
Edit bug report at https://bugs.php.net/bug.php?id=64782edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64782r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64782r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64782r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64782r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64782r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64782r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64782r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64782r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64782r=support
Expected behavior: https://bugs.php.net/fix.php?id=64782r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64782r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64782r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64782r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64782r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64782r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64782r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64782r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64782r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64782r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64782r=mysqlcfg
Req #64782 [Com]: SplFileObject constructor make $context optional / give it a default value
Edit report at https://bugs.php.net/bug.php?id=64782edit=1
ID: 64782
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:SplFileObject constructor make $context optional /
give it a default value
Status: Open
Type: Feature/Change Request
Package:SPL related
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
Correction: The line $this-levels = new Levels(); in the test-script above
needs to be removed.
Addendum: The following variant shows the boilerplate code this needs to get
away with the error:
?php
class Myfile extends SplFileObject
{
public function __construct($file_name, $open_mode = r, $use_include_path
= FALSE, $context = NULL) {
if ($context === NULL) {
parent::__construct($file_name, $open_mode, $use_include_path);
} else {
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
}
Previous Comments:
[2013-05-07 09:57:03] hanskrentel at yahoo dot de
Description:
When extending from SplFileObject and overwriting the constructor, it is not
easily possible to override the parent one because for the last parameter
$context
one can not provide an optional default.
Therefore it requires (somewhat needles) if-branched code only to deal with the
$context not passed case when calling the parents constructor.
It would be nice if $context does accept NULL then if I do not want to use any
context but need to specify the parameter.
Test script:
---
?php
class Myfile extends SplFileObject
{
public function __construct($file_name, $open_mode = r, $use_include_path
= FALSE, $context = NULL) {
$this-levels = new Levels();
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
$file = new MyFile(__FILE__);
Expected result:
It should not give any warning or error.
Actual result:
--
Warning: Missing argument 4 for Myfile::__construct(), called in [pointing to
the
line $file = new MyFile(__FILE__);] and defined in [pointing to the line
public function __construct($file_name, $open_mode = r, $use_include_path =
FALSE, $context = NULL) {]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64782edit=1
Bug #64761 [Com]: rebinding of closures doesn't work when they are declared in a static method
Edit report at https://bugs.php.net/bug.php?id=64761edit=1
ID: 64761
Comment by: hanskrentel at yahoo dot de
Reported by:netmosfera at gmail dot com
Summary:rebinding of closures doesn't work when they are
declared in a static method
Status: Wont fix
Type: Bug
Package:*General Issues
Operating System: any
PHP Version:5.5.0beta4
Block user comment: N
Private report: N
New Comment:
@laruence: This is not by design. Please take a second look on this report.
Thank
you. You probably want to summon ircmaxell for help.
Previous Comments:
[2013-05-03 23:44:25] netmosfera at gmail dot com
makes no sense to me!
also in the global scope $this isn't available, but rebind does work!
[2013-05-03 15:28:02] larue...@php.net
it's by design.
if you create a closure within a scope, then the function actually is a
METHOD, thus must be bound to current object(this) or static.
for your example, since the closure is create in a static function blah, which
makes no this avaliable while creating closure, then the closure is created
as
static ..
[2013-05-02 13:39:28] netmosfera at gmail dot com
Description:
?
class Test
{
public $clos;
public $bobo = 22;
static function blah(){
return new static(function(){ echo $this-bobo; });
}
function __construct(\Closure $c)
{
$this-clos = $c-bindTo($this, $this);
}
}
// perfectly fine when closure is declared in global space
$a = new Test(function(){ echo $this-bobo; });
$clos = $a-clos;
$clos();
// binding doesn't work when closure is declared in a static method
$a = Test::blah();
$clos = $a-clos;
$clos();
// results in: Warning: Cannot bind an instance to a static closure
--
Edit this bug report at https://bugs.php.net/bug.php?id=64761edit=1
Bug #39493 [Com]: simplexml_load_file does not obey default stream context
Edit report at https://bugs.php.net/bug.php?id=39493edit=1
ID: 39493
Comment by: hanskrentel at yahoo dot de
Reported by:RQuadling at GMail dot com
Summary:simplexml_load_file does not obey default stream
context
Status: Not a bug
Type: Bug
Package:SimpleXML related
Operating System: Windows XP SP2
PHP Version:5CVS-2006-11-13 (snap)
Block user comment: N
Private report: N
New Comment:
I know this feedback is later, to whom it may concern: Setting the stream
context
in libxml is possible via:
libxml_set_streams_context()
See http://php.net/libxml_set_streams_context for more information. This is
probably still worth to have this documented here in the issue tracker.
Previous Comments:
[2006-11-13 14:09:35] RQuadling at GMail dot com
What about open_basedir, and other file access restrictions?
Is it possible that all the security used within PHP can be bypassed using this
library?
A potential security risk surely!
But, as you mentioned libxml, this can be solved by using
libxml_set_streams_context.
So, whereas I've got ...
$r_default_context = stream_context_get_default
(
array
(
'http' = array
(
'proxy' = 'tcp://127.0.0.1:8080',
'request_fulluri' = True,
),
)
);
I can add ...
libxml_set_streams_context($r_default_context);
I think.
Testing ...
Yep!
I'll be adding a user notes relating to this as it stumped me!
Thanks for the help.
Maybe, with windows being used more and more for PHP, this should be a
documentation issue?
[2006-11-13 10:29:27] tony2...@php.net
simplexml_load_file() is just a wrapper for libxml2 functions, which apparently
know nothing about stream context etc.
[2006-11-13 10:14:54] RQuadling at GMail dot com
Description:
I'm behind a MS ISA server using NTLM Authentication which is unsupported by
PHP.
To allow PHP through, I use Python and the NTLM Authentication Proxy Server
(further details for this at http://rquadling.php1h.com).
I then use an auto_prepend_file entry to include a default context assignment
to route http traffic to my the proxy.
This works fine for both CLI and ISAPI operations.
The simplexml_load_file() function does not have a context facility. It also
does not use the same mechanism to get data OR it is ignoring the default
context setup.
The example code is just to show the error.
If you are NOT using contexts or you are have direct access to the outside
world, then you will not see the problem.
My NTLM APS logs do not show 2 requests to the external data. Only 1 - the
file_get_contents() call.
Reproduce code:
---
?php
// Define the default, system-wide context. - COPIED FROM
auto_prepended_file.php
$r_default_context = stream_context_get_default
(
array
(
'http' = array
( // All HTTP requests are passed through the local
NTLM proxy server on port 8080.
'proxy' = 'tcp://127.0.0.1:8080',
'request_fulluri' = True,
),
)
);
echo file_get_contents('http://www.people.com.cn/rss/politics.xml');
$xml = simplexml_load_file('http://www.people.com.cn/rss/politics.xml');
?
Expected result:
?xml version=1.0 encoding=GB2312?
rss version=2.0
channel
title#9571;·#9472;#9484;ð#9516;#9580;#9532;/title
linkhttp://politics.people.com.cn/link
languagezh_CN/language
copyrightCopyright ? 1997-2006 by www.people.com.cn. all rights
reserved/copyright
pubDate2006-11-13 16:40:00/pubDate
[SNIP]
pubDate2006-11-13 16:43:03/pubDate
/item
/channel
/rss
Actual result:
--
?xml version=1.0 encoding=GB2312?
rss version=2.0
channel
title#9571;·#9472;#9484;ð#9516;#9580;#9532;/title
linkhttp://politics.people.com.cn/link
languagezh_CN/language
copyrightCopyright ? 1997-2006 by www.people.com.cn. all rights
reserved/copyright
pubDate2006-11-13 16:40:00/pubDate
[SNIP]
pubDate2006-11-13 16:43:03/pubDate
/item
/channel
/rss
Warning: simplexml_load_file(http://www.people.com.cn/rss/politics.xml): failed
to open stream: HTTP request failed! HTTP/1.1 403 Forbidden ( The ISA Server
denies the specified Uniform Resource Locator (URL). )
in C:\noCX.php on line 16
Warning: simplexml_load_file(): I/O warning : failed to load external entity
http://www.people.com.cn/rss/politics.xml; in C:\noCX.php on line 16
--
Edit this bug report at https
[PHP-BUG] Bug #64646 [NEW]: \r in output removes characters
From: hanskrentel at yahoo dot de Operating system: Windows XP PHP version: 5.4.14 Package: *General Issues Bug Type: Bug Bug description:\r in output removes characters Description: I stumbled over a problem that looks to be Windows only. When outputting the \r character, other parts of the output seems to be eaten up: Test script: --- php -r echo a\rb; Expected result: a\rb Actual result: -- b -- Edit bug report at https://bugs.php.net/bug.php?id=64646edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64646r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64646r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64646r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64646r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64646r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64646r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64646r=needscript Try newer version: https://bugs.php.net/fix.php?id=64646r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64646r=support Expected behavior: https://bugs.php.net/fix.php?id=64646r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64646r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64646r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64646r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64646r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64646r=dst IIS Stability: https://bugs.php.net/fix.php?id=64646r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64646r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64646r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64646r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64646r=mysqlcfg
Bug #64646 [Opn-Csd]: \r in output removes characters
Edit report at https://bugs.php.net/bug.php?id=64646edit=1 ID: 64646 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:\r in output removes characters -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: Windows XP PHP Version:5.4.14 Block user comment: N Private report: N New Comment: CR meaning. ... Previous Comments: [2013-04-13 23:46:10] hanskrentel at yahoo dot de Description: I stumbled over a problem that looks to be Windows only. When outputting the \r character, other parts of the output seems to be eaten up: Test script: --- php -r echo a\rb; Expected result: a\rb Actual result: -- b -- Edit this bug report at https://bugs.php.net/bug.php?id=64646edit=1
Bug #64580 [Com]: sort() triggers type-conversion notice
Edit report at https://bugs.php.net/bug.php?id=64580edit=1 ID: 64580 Comment by: hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:sort() triggers type-conversion notice Status: Not a bug Type: Bug Package:Arrays related PHP Version:5.4.13 Block user comment: N Private report: N New Comment: To demonstrate that sort does work (maybe not a full proof but a good demo at least) - despite the fact the object can not be converted to int, it is treated as if it would be the integer one. Demo: http://3v4l.org/2XBBi Output for 5.1.0 - 5.5.0beta2: sort caused 43 error(s) in an array of 24 member(s) of which 4 are object(s). sort()-result: 0, 0, 1, 1, 1, 1, obj(1), obj(1.2), obj(2), obj(2.1), 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3 Output for 4.3.0 - 5.0.5: sort caused 0 error(s) in an array of 24 member(s) of which 4 are object(s). sort()-result: 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, obj(1), obj(1.2), obj(2), obj(2.1) The earlier versions show how arrays are still treated today. Without any warning and larger than anything else. Previous Comments: [2013-04-04 12:50:49] hanskrentel at yahoo dot de The `sort()` function explicitly states: don't change types If no types are changed, why do I get a type conversion notice? I can understand that for comparing those values, a sort-value of each array member must be obtained to create to do sorting, however, as long as the sort is successful, this should not create any notices. [2013-04-04 12:47:18] ni...@php.net Nothing to do with sort() this is just the usual behavior of the operator. Try doing just 1 new stdClass and you'll get the same notice. [2013-04-04 12:43:42] hanskrentel at yahoo dot de Description: Under specific circumstances the sort() function with the `SORT_REGULAR` sort- flag triggers type-conversion notices even it is documented that no type- conversion is done[1]: SORT_REGULAR - compare items normally (don't change types) This notice is *only* given if an object value is sorted with an integer or float. The notices for these two cases are as following: Notice: Object of class stdClass could not be converted to int Notice: Object of class stdClass could not be converted to double Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl). The sort() function returns TRUE despite the Notice and as far I was able to find out, the sorting is done, so this looks correct to me. Also this error only happens with sorting objects with integers and floats. I also tested against NULL, boolean (TRUE/FALSE), string, array, object and resource and these did not trigger the notice. I would not classify this as documentation bug because these are very specific circumstances which makes me assume that this is not the intended behavior. Something might have been just overlooked for these two cases with `SORT_REGULAR`. It should be said that there are related issues documented in #54980 and #54259 over which I originally stumbled. [1] http://php.net/sort Test script: --- ?php $subject = [1, (object) ['prop' = 'value']]; sort($subject); Actual result: -- Notice: Object of class stdClass could not be converted to int in [...] on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=64580edit=1
[PHP-BUG] Bug #64580 [NEW]: sort() triggers type-conversion notice
From: hanskrentel at yahoo dot de Operating system: PHP version: 5.4.13 Package: Arrays related Bug Type: Bug Bug description:sort() triggers type-conversion notice Description: Under specific circumstances the sort() function with the `SORT_REGULAR` sort- flag triggers type-conversion notices even it is documented that no type- conversion is done[1]: SORT_REGULAR - compare items normally (don't change types) This notice is *only* given if an object value is sorted with an integer or float. The notices for these two cases are as following: Notice: Object of class stdClass could not be converted to int Notice: Object of class stdClass could not be converted to double Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl). The sort() function returns TRUE despite the Notice and as far I was able to find out, the sorting is done, so this looks correct to me. Also this error only happens with sorting objects with integers and floats. I also tested against NULL, boolean (TRUE/FALSE), string, array, object and resource and these did not trigger the notice. I would not classify this as documentation bug because these are very specific circumstances which makes me assume that this is not the intended behavior. Something might have been just overlooked for these two cases with `SORT_REGULAR`. It should be said that there are related issues documented in #54980 and #54259 over which I originally stumbled. [1] http://php.net/sort Test script: --- ?php $subject = [1, (object) ['prop' = 'value']]; sort($subject); Actual result: -- Notice: Object of class stdClass could not be converted to int in [...] on line 3 -- Edit bug report at https://bugs.php.net/bug.php?id=64580edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64580r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64580r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64580r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64580r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64580r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64580r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64580r=needscript Try newer version: https://bugs.php.net/fix.php?id=64580r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64580r=support Expected behavior: https://bugs.php.net/fix.php?id=64580r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64580r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64580r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64580r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64580r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64580r=dst IIS Stability: https://bugs.php.net/fix.php?id=64580r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64580r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64580r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64580r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64580r=mysqlcfg
Bug #64580 [Com]: sort() triggers type-conversion notice
Edit report at https://bugs.php.net/bug.php?id=64580edit=1 ID: 64580 Comment by: hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:sort() triggers type-conversion notice Status: Not a bug Type: Bug Package:Arrays related PHP Version:5.4.13 Block user comment: N Private report: N New Comment: The `sort()` function explicitly states: don't change types If no types are changed, why do I get a type conversion notice? I can understand that for comparing those values, a sort-value of each array member must be obtained to create to do sorting, however, as long as the sort is successful, this should not create any notices. Previous Comments: [2013-04-04 12:47:18] ni...@php.net Nothing to do with sort() this is just the usual behavior of the operator. Try doing just 1 new stdClass and you'll get the same notice. [2013-04-04 12:43:42] hanskrentel at yahoo dot de Description: Under specific circumstances the sort() function with the `SORT_REGULAR` sort- flag triggers type-conversion notices even it is documented that no type- conversion is done[1]: SORT_REGULAR - compare items normally (don't change types) This notice is *only* given if an object value is sorted with an integer or float. The notices for these two cases are as following: Notice: Object of class stdClass could not be converted to int Notice: Object of class stdClass could not be converted to double Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl). The sort() function returns TRUE despite the Notice and as far I was able to find out, the sorting is done, so this looks correct to me. Also this error only happens with sorting objects with integers and floats. I also tested against NULL, boolean (TRUE/FALSE), string, array, object and resource and these did not trigger the notice. I would not classify this as documentation bug because these are very specific circumstances which makes me assume that this is not the intended behavior. Something might have been just overlooked for these two cases with `SORT_REGULAR`. It should be said that there are related issues documented in #54980 and #54259 over which I originally stumbled. [1] http://php.net/sort Test script: --- ?php $subject = [1, (object) ['prop' = 'value']]; sort($subject); Actual result: -- Notice: Object of class stdClass could not be converted to int in [...] on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=64580edit=1
[PHP-BUG] Bug #64438 [NEW]: proc_open hangs with stdin/out with 4097+ bytes
From: hanskrentel at yahoo dot de
Operating system: windows
PHP version: 5.4.13
Package: Filesystem function related
Bug Type: Bug
Bug description:proc_open hangs with stdin/out with 4097+ bytes
Description:
The stream used to read data from stdin/out/err hangs if the data passed is
getting larger than 4096 (taht is 4097 and above), always.
Test script:
---
error_reporting(E_ALL);
$cmd = 'php -r fwrite(STDOUT, $in = file_get_contents(\'php://stdin\'));
fwrite(STDERR, $in);';
$descriptors = array(array('pipe', 'r'), array('pipe', 'w'), array('pipe',
'w'));
$stdin = str_repeat('*', 4097);
$options = array_merge(array('suppress_errors' = true, 'binary_pipes' =
true, 'bypass_shell' = false));
$process = proc_open($cmd, $descriptors, $pipes, getcwd(), array(),
$options);
foreach ($pipes as $pipe) {
stream_set_blocking($pipe, false);
}
$writePipes = array($pipes[0]);
$stdinLen = strlen($stdin);
$stdinOffset = 0;
unset($pipes[0]);
while ($pipes || $writePipes) {
$r = $pipes;
$w = $writePipes;
$e = null;
$n = stream_select($r, $w, $e, 60);
if (false === $n) {
break;
} elseif ($n === 0) {
proc_terminate($process);
}
if ($w) {
$written = fwrite($writePipes[0], (binary)substr($stdin,
$stdinOffset), 8192);
if (false !== $written) {
$stdinOffset += $written;
}
if ($stdinOffset = $stdinLen) {
fclose($writePipes[0]);
$writePipes = null;
}
}
foreach ($r as $pipe) {
$type = array_search($pipe, $pipes);
$data = fread($pipe, 8192);
if (false === $data || feof($pipe)) {
fclose($pipe);
unset($pipes[$type]);
}
}
}
Expected result:
Process executes in a fraction of a second and finishes with exit code 0
Actual result:
--
Process executes and hangs.
--
Edit bug report at https://bugs.php.net/bug.php?id=64438edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64438r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64438r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64438r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64438r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64438r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64438r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64438r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64438r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64438r=support
Expected behavior: https://bugs.php.net/fix.php?id=64438r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64438r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64438r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64438r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64438r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64438r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64438r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64438r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64438r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64438r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64438r=mysqlcfg
Bug #51800 [Com]: proc_open on Windows hangs forever
Edit report at https://bugs.php.net/bug.php?id=51800edit=1
ID: 51800
Comment by: hanskrentel at yahoo dot de
Reported by:ph dot wolfer at googlemail dot com
Summary:proc_open on Windows hangs forever
Status: Assigned
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:*
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
The problem with exactly 4097 bytes has just been reported here:
https://bugs.php.net/bug.php?id=64438
It's a follow up to https://bugs.php.net/bug.php?id=60120 which is wrongly
closed
as resolved.
this and the many other issues show that the flaw is not fixed:
https://bugs.php.net/bug.php?id=51800
https://bugs.php.net/bug.php?id=60120
https://bugs.php.net/bug.php?id=64438
Previous Comments:
[2012-04-12 14:41:35] andremiguelcruz at msn dot com
I hope this gets fixed soon both on 5.4 and 5.3.
Is very frustrating because I have this bug while using symfony2 with scss.
[2012-04-09 12:49:12] paj...@php.net
it seems that the issue is on main/streams.c:679
if (stream-writepos - stream-readpos (off_t)size) {
where writepos and readpos are equals.
Anatolyi, please take a look at it.
[2012-04-08 21:21:34] s...@php.net
I could reproduce this on PHP 5.4.0 as soon as $data is longer than 4096 bytes.
With $data = str_repeat(a, 4097); in process.php it hangs forever, while with
any number until 4096 it passes.
[2012-02-19 14:37:42] nicolas dot sauveur at gmail dot com
This seems similar as https://bugs.php.net/bug.php?id=60120 .
Only partially fixed for me ( thus not fixed ) in php 5.3.9.
[2010-05-12 17:31:30] ph dot wolfer at googlemail dot com
Description:
On Windows, if you use proc_open to open another process and if you use a pipe
for STDERR, the script will hang when trying to read from STDOUT or STDERR if
the opened process outputs a lot of data.
See the example below. The called script process.php is a simple script which
writes some data to STDOUT and STDERR:
$data = str_repeat(a, 1);
fwrite(STDOUT, $data);
fwrite(STDERR, $data);
exit(0);
If called as shown below, the script will hang in the loop that reads the
STDOUT pipe. The same would happen if you would read the STDERR pipe before. If
you lower the amount of data in process.php the script will run to the end. In
my tests everything below ~2000 bytes was ok, above this value the script hang.
If you change the script below to not include the STDERR descriptor or if you
change the STDERR descriptor to a file output everything will work fine. Also
if you close the STDERR pipe before reading from STDOUT it will work. There
seems to be some deadlock.
The same script works fine on Linux.
This was tested with Windows Server 2008, IIS, PHP 5.2.13. But I have seen this
on other Windows configurations as well.
Test script:
---
?php
$cmd = \C:/Program Files/php/php.exe\ process.php;
$status;
$stdout = ;
$stderr = ;
$pipes = array();
$descriptors = array(
0 = array(pipe, r),// stdin
1 = array(pipe, w),// stdout
2 = array(pipe, w) // stderr
);
$process = proc_open($cmd, $descriptors, $pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while (!feof($pipes[1]))
$stdout .= fread($pipes[1], 1024);
fclose($pipes[1]);
while (!feof($pipes[2]))
$stderr .= fread($pipes[2], 1024);
fclose($pipes[2]);
$status = proc_close($process);
}
print_r(array(
status = $status,
stdout = $stdout,
stderr = $stderr,
));
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=51800edit=1
Bug #60120 [Com]: proc_open hangs with stdin/out with 2048+ bytes
Edit report at https://bugs.php.net/bug.php?id=60120edit=1
ID: 60120
Comment by: hanskrentel at yahoo dot de
Reported by:paj...@php.net
Summary:proc_open hangs with stdin/out with 2048+ bytes
Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: windows
PHP Version:Irrelevant
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
In case you don't want to re-open this issue as not fixed, I made a more
specific
report with 4097+ bytes pipes that cause a hang here:
https://bugs.php.net/bug.php?id=64438
Previous Comments:
[2012-07-24 23:39:19] ras...@php.net
Automatic comment on behalf of pajoye
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=8bd6b9d87af4ec3953bd760c65aea506c70b840b
Log: - fixed bug #60120, proc_open's streams may hang with stdin/out/err when
the data exceeds or is equal to 2048 bytes
[2012-04-18 09:48:13] larue...@php.net
Automatic comment on behalf of pajoye
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=8bd6b9d87af4ec3953bd760c65aea506c70b840b
Log: - fixed bug #60120, proc_open's streams may hang with stdin/out/err when
the data exceeds or is equal to 2048 bytes
[2012-02-19 14:48:40] nicolas dot sauveur at gmail dot com
seems similar to https://bugs.php.net/bug.php?id=51800
[2012-02-19 14:34:42] nicolas dot sauveur at gmail dot com
On my install of php 5.3.9 (windows 7 wamp server 2, apache 2.2.21), the bug
has
only been fixed for 2048 to 4096 bytes. Above that, proc_open still hangs for
me.
I use the same test as above, with
$stdin = str_repeat('*', 4097 );
[2011-10-26 08:41:57] paj...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
yes (see the commit tab :), I forgot to close it. Thanks for the headup!
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
https://bugs.php.net/bug.php?id=60120
--
Edit this bug report at https://bugs.php.net/bug.php?id=60120edit=1
Bug #52858 [Com]: dom_import_simplexml() doesn't work on newly created SimpleXMLElement nodes
Edit report at https://bugs.php.net/bug.php?id=52858edit=1
ID: 52858
Comment by: hanskrentel at yahoo dot de
Reported by:tatarynowicz at gmail dot com
Summary:dom_import_simplexml() doesn't work on newly created
SimpleXMLElement nodes
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Windows 7
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Please compare what you do with:
$xml-three-addChild('alpha');
You will get a warning:
Warning: SimpleXMLElement::addChild(): Cannot add child. Parent is not a
permanent member of the XML tree
If you extend from SompleXMLElement you probably want to add a similar warning
for your function. You can check for the condition this way:
if ($this[0] == NULL) {
$where = __CLASS__ . '::' . __FUNCTION__ . '(): ';
$what = 'Cannot add child. Parent is not a permanent member of the XML
tree';
trigger_error($where . $what, E_USER_WARNING);
return;
}
I hope this is helpful and makes the bigger picture more clear that this is how
SimpleXMLElement works.
You can however create your own type that does know how to add this on the fly,
however due to the magic nature of SimpleXMLElement, it is not possible as long
as you extend from
SimpleXMLElement.
It requires you to create a decorator and write code for that part of the magic
your own and delegate the rest to the SimpleXMLElement decoratee / subject.
Previous Comments:
[2010-09-16 05:51:22] tatarynowicz at gmail dot com
Description:
The problem is readily apparent when you run the test script. When
SimpleXMLElement dynamically creates a child element, and you directly call a
method on the child element, the $this context is apparently not a proper
SimpleXMLElement, i.e. dom_import_simplexml() does not accept it as input.
class MyXML extends SimpleXMLElement {
public function cdata($text) {
dom_import_simplexml($this);
}
}
$xml = new MyXML('foo/');
$xml-three-cdata('Three');
Test script:
---
?php
class MyXML extends SimpleXMLElement {
public function cdata($text) {
$node = dom_import_simplexml($this);
$owner = $node-ownerDocument;
$node-appendChild($owner-createCDATASection($text));
return $this;
}
}
$xml = new MyXML('foo/');
// works
$xml-one = 'One';
// also works
$xml-two = '';
$xml-two-cdata('Two');
// doesn't work
$xml-three-cdata('Three');
print $xml-asXML();
Expected result:
?xml version=1.0?
foooneOne/onetwo![CDATA[Two]]/twothree![CDATA[Three]]/three/foo
Actual result:
--
Warning: dom_import_simplexml(): Invalid Nodetype to import in
C:\WWW\Work\WC\www\dom.php on line 5
Notice: Trying to get property of non-object in C:\WWW\Work\WC\www\dom.php on
line
6
Fatal error: Call to a member function appendChild() on a non-object in
C:\WWW\Work\WC\www\dom.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=52858edit=1
[PHP-BUG] Req #64185 [NEW]: is_callable does not check syntax
From: hanskrentel at yahoo dot de Operating system: PHP version: 5.4.11 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:is_callable does not check syntax Description: Using is_callable with the syntax_only parameter set to true does actually *not* check the syntax, for example of a valid classname or FQCN. Also not for the method name. My feature request is, that it will always check those strings according to the rules set in the PHP parser of the same PHP version the function ships with so that it can be used to validate PHP syntax as well. Same for calls with :: for static class name method calls. Test script: --- var_dump(is_callable(['', ''], true)); var_dump(is_callable(['', 'method'], true)); var_dump(is_callable(['0', 'method'], true)); var_dump(is_callable(['0\\foo', 'method'], true)); var_dump(is_callable(['\\0\\foo', 'method'], true)); Expected result: bool(false) bool(false) bool(false) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(true) bool(true) bool(true) -- Edit bug report at https://bugs.php.net/bug.php?id=64185edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64185r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64185r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64185r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64185r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64185r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64185r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64185r=needscript Try newer version: https://bugs.php.net/fix.php?id=64185r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64185r=support Expected behavior: https://bugs.php.net/fix.php?id=64185r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64185r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64185r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64185r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64185r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64185r=dst IIS Stability: https://bugs.php.net/fix.php?id=64185r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64185r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64185r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64185r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64185r=mysqlcfg
Req #64185 [Com]: is_callable does not check syntax
Edit report at https://bugs.php.net/bug.php?id=64185edit=1 ID: 64185 Comment by: hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:is_callable does not check syntax Status: Open Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.11 Block user comment: N Private report: N New Comment: NikiC was so friendly to just remind me that checking for the method name *is* limited because of __call and __callStatic (basically everything for a method name works, including a zero-length string). So this feature request is actually more about the classname validation then the method name validation. Previous Comments: [2013-02-10 16:04:21] hanskrentel at yahoo dot de Description: Using is_callable with the syntax_only parameter set to true does actually *not* check the syntax, for example of a valid classname or FQCN. Also not for the method name. My feature request is, that it will always check those strings according to the rules set in the PHP parser of the same PHP version the function ships with so that it can be used to validate PHP syntax as well. Same for calls with :: for static class name method calls. Test script: --- var_dump(is_callable(['', ''], true)); var_dump(is_callable(['', 'method'], true)); var_dump(is_callable(['0', 'method'], true)); var_dump(is_callable(['0\\foo', 'method'], true)); var_dump(is_callable(['\\0\\foo', 'method'], true)); Expected result: bool(false) bool(false) bool(false) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(true) bool(true) bool(true) -- Edit this bug report at https://bugs.php.net/bug.php?id=64185edit=1
Req #53950 [Com]: Add a way to configure where libxml searches for Catalog Files
Edit report at https://bugs.php.net/bug.php?id=53950edit=1 ID: 53950 Comment by: hanskrentel at yahoo dot de Reported by:gordon at onlinehome dot de Summary:Add a way to configure where libxml searches for Catalog Files Status: Assigned Type: Feature/Change Request Package:*XML functions Operating System: any PHP Version:Irrelevant Assigned To:rrichards Block user comment: N Private report: N New Comment: setenv(XML_CATALOG_FILES=/path/to/catalog.xml); should normally work (depending which dialect that as) if it's set before PHP starts and loads the extension and the path to the catalog XML file does not contain any spaces (which has a special meaning). See as well: http://www.cafeconleche.org/books/effectivexml/chapters/47.html http://www.chlab.ch/blog/archives/php/soap/cache-soap-envelope-schema-schema- validation http://wp.me/pLEEp-nlj To change things at runtime, make use of libxml_set_external_entity_loader and implement a catalog parser your own. You then can use catalogs as you wish at runtime. Previous Comments: [2011-12-06 17:34:01] Marko dot Voss at fiz-Karlsruhe dot de The user can change the default catalog behaviour by redirecting queries to its own set of catalogs. This can be done by setting the XML_CATALOG_FILES environment variable to a list of catalogs, an empty one should deactivate loading the default /etc/xml/catalog default catalog. If I understand this right, you can use this code to set your own catalog: setenv(XML_CATALOG_FILES=/path/to/catalog.xml); I tried that, because I have to use xml catalog somehow, without overwriting the http stream wrapper, which is a non-threadsafe way to do this. However, the catalog.xml I specified using setenv seems not to be used by libxml2. [2011-02-08 19:27:00] rricha...@php.net Assign to self as I asked him to open this [2011-02-08 19:18:43] cataphr...@php.net This, by itself, makes it inviable to write a PHP function that allows replacing the default catalog unless some (probably expensive, since a catalog file must be read) on request startup/shutdown is used. The unless part doesn't actually make sense in the multi-threading versions of PHP. [2011-02-08 19:14:49] cataphr...@php.net I know very little of libxml2, but as far as I infer from http://xmlsoft.org/catalog.html and from the code in catalog.c, there is no way to specify a global catalog in a thread-local manner. This, by itself, makes it inviable to write a PHP function that allows replacing the default catalog unless some (probably expensive, since a catalog file must be read) on request startup/shutdown is used. libxml2 supports per-document catalogs, but from what I see, your document must contain an oasis-xml-catalog processing instruction, like this: ?xml version=1.0? ?oasis-xml-catalog catalog=http://example.com/catalog.xml;? !DOCTYPE doc PUBLIC -//Example//DTD Document V1.0//EN http://www.example.com/schema/doc.dtd; There is another alternative, which is using an external entity loader (see http://xmlsoft.org/html/libxml-parser.html#xmlSetExternalEntityLoader ), but this is less convenient, though probably we could also expose some functions to deal with catalogs for use in the user-supplied callback. I could implement this, but I'm hopping someone else with more libxml2 knowledge could tell if my analysis is correct. [2011-02-07 17:16:37] gordon at onlinehome dot de Description: Libxml can use catalog files to provide a local cache mechanism allowing to load the entities associated to public identifiers or remote resources. There is currently no way to configure the catalog file path from PHP. Configuring the path in libxml itself seems possible: The user can change the default catalog behaviour by redirecting queries to its own set of catalogs. This can be done by setting the XML_CATALOG_FILES environment variable to a list of catalogs, an empty one should deactivate loading the default /etc/xml/catalog default catalog. It would be nice if PHP's libxml extension would provide a way to set the path somehow. This could be helpful when validating documents with remote System Identifiers, like any HTML DTD. Or simply to bundle files with an application. Related Resources: - http://xmlsoft.org/catalog.html - http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic - http://bugs.php.net/48080 - http://bugs.php.net/32426
Bug #63769 [Com]: file:// protocol does not support percent-encoded characters
Edit report at https://bugs.php.net/bug.php?id=63769edit=1
ID: 63769
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:file:// protocol does not support percent-encoded
characters
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
@ab:
Consider you have a file containing a space in the filename, and you *need to*
specify the filename in form of a file:// URI for which space is a special
character that needs proper URL-encoding.
That file://-URI btw is set in an environemnt variable that requires it
(XML_CATALOG_FILES).
Domdocument in PHP internally is then using that file://-URI and can't process
it properly because the wrapper is not able to properly decode the path
information.
You actually pretty well demonstrate the problem in your example:
php -r echo file_get_contents('file://C:/my/path/catalog%202.xml');
percent filename
Is obviously wrong. %20 in a file://-URI is an ecoded space, so the content
space filename
needs to be output instead. The filename you meant is properly written as:
php -r echo file_get_contents('file://C:/my/path/catalog%25202.xml');
percent filename
compare: http://tools.ietf.org/html/rfc3986#section-2.1
Please add that example to yours because only if you have the two opposite
cases (encoded *and* decoded) you can actually work out concrete results. You
are just having two times the same example,
of which I think both shows the
same form of wrong: Missing encoding in those URIs.
Which brings me to the point: Is there actually any interest to fix this? I
mean there is not much standing in the way if you ask me. Normally users are
not using the file:// URIs at all.
Those who did most likely used the space (or would have complained earlier
here, but I could find no bug-report). The only edge-case I can see is with
files containing percent-signs, however how
likely is that at all?
Let me know if I would sponsor some well written patch how the chances would be
to get this fixed.
Previous Comments:
[2013-01-08 17:12:54] a...@php.net
@hanskrentel
That's my test:
- create file 'catalog%202.xml' with content percent filename
- create file 'catalog 2.xml' with content space filename
- then run
php -r echo file_get_contents('file://C:/my/path/catalog%202.xml');
percent filename
- then run
php -r echo file_get_contents('file://C:/my/path/catalog 2.xml');
space filename
That's pretty straight forward. That's what I mean - no decoding, both are
valid filenames. The decoding should be done in your app depending on what it
needs. In your example - you create 'catalog 2.xml' and are trying to stat
'catalog%202.xml', literally. But 'catalog%202.xml' doesn't exist.
[2013-01-06 07:03:56] anon at anon dot anon
Actually, hold on a sec, plus signs are *not* supposed to be decoded here. That
means that file names containing plus signs would not be broken by a fix, and
only file names containing a '%xx' (where x is a hexit) sequence would be
affected, which is probably uncommon. Perhaps you have a chance.
[2013-01-06 06:38:45] anon at anon dot anon
You would have wanted to access it via 'file:///C:/temp/catalog%%25202.xml'
Actually, 'catalog%25202.xml', but I know, I'm agreeing with you. I'm just
pointing out that this erroneous behavior may be depended on somewhere in some
PHP script, where the author, in good faith, did whatever made things work. I
assume you're going to pass your path through urldecode (or not encode it in
the first place), and then you'll be one of them.
In any case, you're unlikely to get any support here. The reviewers here don't
do much except dismiss things as 'Not a bug' and once they've successfully done
that they lose interest. C'est le PHP.
[2013-01-06 01:29:30] hanskrentel at yahoo dot de
If you would create a file named
catalog%202.xml.
You would have wanted to access it via:
'file:///C:/temp/catalog%%25202.xml'
which as well does not work. I'm not doing a bug report here to be treated like
an idiot. I better suggest you piss completely off
instead of leaving such an idiotic comment. My 2 cents.
[2012-12-20 16:27:43] anon at anon dot anon
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not*
work.
Unfortunately it does work, if you create a file literally named
catalog%202.xml. PHP's behavior is broken but it's impossible to alter it
without breaking
Bug #63769 [Com]: file:// protocol does not support percent-encoded characters
Edit report at https://bugs.php.net/bug.php?id=63769edit=1
ID: 63769
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:file:// protocol does not support percent-encoded
characters
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Pierre, not helpful. Should I say as usual?
I explain you briefly, so you can see how easily you fool yourself:
You point to some standard reference (here to the MSDN) to make up the argument
that % can be part of a file-name. I never neglected that. So what do you want
to say with that link? Probably that there is some standardization in
file-names inside an OS?
Well that's fine.
My point is that some standard with the URI standardization is not properly
implemented in PHP. A very common standard btw. despite the file:// URI is not
really standardized, URI and percent encoding *is*.
Now you bring in some other standard. You probably wanted to create the
impression that PHP itself would actually follow that standard, but what should
I tell you: Naturally like not following the URI standard (as pointed out in
this issue), the Windows rules for valid file names aren't properly implemented
either (!!!).
But this is not what my bug-report is about.
Or was it that you just wanted to give the example that PHP does not even needs
the file-system file-naming rules because it makes it's own ones? That it does
not have to follow these, because it's superior?
Previous Comments:
[2013-01-16 17:40:40] paj...@php.net
it is your job to decode it, file:// does not have and does not follow the %
used
in other areas.
btw, paths on windows can contain the %, see http://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247(v=vs.85).aspx for a list of not allowed
characters.
[2013-01-16 16:18:41] hanskrentel at yahoo dot de
@ab:
Consider you have a file containing a space in the filename, and you *need to*
specify the filename in form of a file:// URI for which space is a special
character that needs proper URL-encoding.
That file://-URI btw is set in an environemnt variable that requires it
(XML_CATALOG_FILES).
Domdocument in PHP internally is then using that file://-URI and can't process
it properly because the wrapper is not able to properly decode the path
information.
You actually pretty well demonstrate the problem in your example:
php -r echo file_get_contents('file://C:/my/path/catalog%202.xml');
percent filename
Is obviously wrong. %20 in a file://-URI is an ecoded space, so the content
space filename
needs to be output instead. The filename you meant is properly written as:
php -r echo file_get_contents('file://C:/my/path/catalog%25202.xml');
percent filename
compare: http://tools.ietf.org/html/rfc3986#section-2.1
Please add that example to yours because only if you have the two opposite
cases (encoded *and* decoded) you can actually work out concrete results. You
are just having two times the same example,
of which I think both shows the
same form of wrong: Missing encoding in those URIs.
Which brings me to the point: Is there actually any interest to fix this? I
mean there is not much standing in the way if you ask me. Normally users are
not using the file:// URIs at all.
Those who did most likely used the space (or would have complained earlier
here, but I could find no bug-report). The only edge-case I can see is with
files containing percent-signs, however how
likely is that at all?
Let me know if I would sponsor some well written patch how the chances would be
to get this fixed.
[2013-01-08 17:12:54] a...@php.net
@hanskrentel
That's my test:
- create file 'catalog%202.xml' with content percent filename
- create file 'catalog 2.xml' with content space filename
- then run
php -r echo file_get_contents('file://C:/my/path/catalog%202.xml');
percent filename
- then run
php -r echo file_get_contents('file://C:/my/path/catalog 2.xml');
space filename
That's pretty straight forward. That's what I mean - no decoding, both are
valid filenames. The decoding should be done in your app depending on what it
needs. In your example - you create 'catalog 2.xml' and are trying to stat
'catalog%202.xml', literally. But 'catalog%202.xml' doesn't exist.
[2013-01-06 07:03:56] anon at anon dot anon
Actually, hold on a sec, plus signs are *not* supposed to be decoded here. That
means that file names containing plus signs would not be broken by a fix, and
only file names containing
[PHP-BUG] Bug #63910 [NEW]: var_dump() on DOMNode is like in PHP 5.4.1
From: hanskrentel at yahoo dot de
Operating system: Win32 / XP
PHP version: 5.4.10
Package: DOM XML related
Bug Type: Bug
Bug description:var_dump() on DOMNode is like in PHP 5.4.1
Description:
If I want to make use of the improvements for DOMNodes with var_dump since
PHP
5.4.1 on my system, I can't. It's just like the old (not-so-much-saying)
output
like before 5.4.1.
It is like that if the changes of which are said that have been introduced
in PHP
5.4.1 (demo: http://3v4l.org/8HfO6 - Changelog named this feature for
5.3.11
Added debug info handler to DOM objects.) are just not there on my
system.
Related: #48527 (You might want to close this for now)
Test script:
---
?php
$DOMDocumentNode = new DOMDocument();
$DOMDocumentNode-loadXML('example a=bTest/example');
$DOMElementNode = $DOMDocumentNode-documentElement;
$DOMAttributeNode = $DOMElementNode-getAttributeNode('a');
$DOMTextNode = $DOMElementNode-firstChild;
var_dump($DOMDocumentNode, $DOMElementNode, $DOMAttributeNode,
$DOMTextNode);
Expected result:
object(DOMDocument)#1 (34) {
[doctype]=
NULL
[implementation]=
string(22) (object value omitted)
[documentElement]=
string(22) (object value omitted)
[actualEncoding]=
NULL
[encoding]=
NULL
[xmlEncoding]=
NULL
[standalone]=
bool(true)
[xmlStandalone]=
bool(true)
[version]=
string(3) 1.0
[xmlVersion]=
string(3) 1.0
[strictErrorChecking]=
bool(true)
[documentURI]=
string(1) /
[config]=
NULL
[formatOutput]=
bool(false)
[validateOnParse]=
bool(false)
[resolveExternals]=
bool(false)
[preserveWhiteSpace]=
bool(true)
[recover]=
bool(false)
[substituteEntities]=
bool(false)
[nodeName]=
string(9) #document
[nodeValue]=
NULL
[nodeType]=
int(9)
[parentNode]=
NULL
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
NULL
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
object(DOMElement)#2 (17) {
[tagName]=
string(7) example
[schemaTypeInfo]=
NULL
[nodeName]=
string(7) example
[nodeValue]=
string(4) Test
[nodeType]=
int(1)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
string(22) (object value omitted)
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(7) example
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
Warning: var_dump(): Not yet implemented in /in/MXnGG on line 18
object(DOMAttr)#3 (20) {
[name]=
string(1) a
[specified]=
bool(true)
[value]=
string(1) b
[ownerElement]=
string(22) (object value omitted)
[schemaTypeInfo]=
NULL
[nodeName]=
string(1) a
[nodeValue]=
string(1) b
[nodeType]=
int(2)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(1) a
[baseURI]=
string(1) /
[textContent]=
string(1) b
}
object(DOMText)#4 (18) {
[wholeText]=
string(4) Test
[data]=
string(4) Test
[length]=
int(4)
[nodeName]=
string(5) #text
[nodeValue]=
string(4) Test
[nodeType]=
int(3)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
NULL
[firstChild]=
NULL
[lastChild]=
NULL
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
Actual result:
--
class DOMDocument#1 (0) {
}
class DOMElement#2 (0) {
}
class DOMAttr#3 (0) {
}
class DOMText#4 (0) {
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63910edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63910r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63910r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63910r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63910r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63910r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63910r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63910r
Bug #63910 [Com]: var_dump() on DOMNode is like in PHP 5.4.1
Edit report at https://bugs.php.net/bug.php?id=63910edit=1
ID: 63910
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:var_dump() on DOMNode is like in PHP 5.4.1
Status: Open
Type: Bug
Package:DOM XML related
Operating System: Win32 / XP
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
Okay, I found out that my report is somewhat bogus.
I had xdebug enabled. Disabling xdebug did reveal the expected output.
[xdebug]
; zend_extension = c:\Programme\PHP-5.4\ext\php_xdebug-2.2.1-5.4-vc9-nts.dll
Previous Comments:
[2013-01-05 15:01:58] hanskrentel at yahoo dot de
Description:
If I want to make use of the improvements for DOMNodes with var_dump since PHP
5.4.1 on my system, I can't. It's just like the old (not-so-much-saying) output
like before 5.4.1.
It is like that if the changes of which are said that have been introduced in
PHP
5.4.1 (demo: http://3v4l.org/8HfO6 - Changelog named this feature for 5.3.11
Added debug info handler to DOM objects.) are just not there on my system.
Related: #48527 (You might want to close this for now)
Test script:
---
?php
$DOMDocumentNode = new DOMDocument();
$DOMDocumentNode-loadXML('example a=bTest/example');
$DOMElementNode = $DOMDocumentNode-documentElement;
$DOMAttributeNode = $DOMElementNode-getAttributeNode('a');
$DOMTextNode = $DOMElementNode-firstChild;
var_dump($DOMDocumentNode, $DOMElementNode, $DOMAttributeNode, $DOMTextNode);
Expected result:
object(DOMDocument)#1 (34) {
[doctype]=
NULL
[implementation]=
string(22) (object value omitted)
[documentElement]=
string(22) (object value omitted)
[actualEncoding]=
NULL
[encoding]=
NULL
[xmlEncoding]=
NULL
[standalone]=
bool(true)
[xmlStandalone]=
bool(true)
[version]=
string(3) 1.0
[xmlVersion]=
string(3) 1.0
[strictErrorChecking]=
bool(true)
[documentURI]=
string(1) /
[config]=
NULL
[formatOutput]=
bool(false)
[validateOnParse]=
bool(false)
[resolveExternals]=
bool(false)
[preserveWhiteSpace]=
bool(true)
[recover]=
bool(false)
[substituteEntities]=
bool(false)
[nodeName]=
string(9) #document
[nodeValue]=
NULL
[nodeType]=
int(9)
[parentNode]=
NULL
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
NULL
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
object(DOMElement)#2 (17) {
[tagName]=
string(7) example
[schemaTypeInfo]=
NULL
[nodeName]=
string(7) example
[nodeValue]=
string(4) Test
[nodeType]=
int(1)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
string(22) (object value omitted)
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(7) example
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
Warning: var_dump(): Not yet implemented in /in/MXnGG on line 18
object(DOMAttr)#3 (20) {
[name]=
string(1) a
[specified]=
bool(true)
[value]=
string(1) b
[ownerElement]=
string(22) (object value omitted)
[schemaTypeInfo]=
NULL
[nodeName]=
string(1) a
[nodeValue]=
string(1) b
[nodeType]=
int(2)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(1) a
[baseURI]=
string(1) /
[textContent]=
string(1) b
}
object(DOMText)#4 (18) {
[wholeText]=
string(4) Test
[data]=
string(4) Test
[length]=
int(4)
[nodeName]=
string(5) #text
[nodeValue]=
string(4) Test
[nodeType]=
int(3)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
NULL
[firstChild]=
NULL
[lastChild]=
NULL
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
Actual result:
--
class DOMDocument#1 (0) {
}
class DOMElement#2 (0) {
}
class DOMAttr#3 (0) {
}
class DOMText#4 (0
Bug #63910 [Com]: var_dump() on DOMNode is like in PHP 5.4.1
Edit report at https://bugs.php.net/bug.php?id=63910edit=1
ID: 63910
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:var_dump() on DOMNode is like in PHP 5.4.1
Status: Open
Type: Bug
Package:DOM XML related
Operating System: Win32 / XP
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
For reference: I create a ticket over at xdebug:
http://bugs.xdebug.org/view.php?
id=913
Previous Comments:
[2013-01-05 16:01:22] hanskrentel at yahoo dot de
Okay, I found out that my report is somewhat bogus.
I had xdebug enabled. Disabling xdebug did reveal the expected output.
[xdebug]
; zend_extension = c:\Programme\PHP-5.4\ext\php_xdebug-2.2.1-5.4-vc9-nts.dll
[2013-01-05 15:01:58] hanskrentel at yahoo dot de
Description:
If I want to make use of the improvements for DOMNodes with var_dump since PHP
5.4.1 on my system, I can't. It's just like the old (not-so-much-saying) output
like before 5.4.1.
It is like that if the changes of which are said that have been introduced in
PHP
5.4.1 (demo: http://3v4l.org/8HfO6 - Changelog named this feature for 5.3.11
Added debug info handler to DOM objects.) are just not there on my system.
Related: #48527 (You might want to close this for now)
Test script:
---
?php
$DOMDocumentNode = new DOMDocument();
$DOMDocumentNode-loadXML('example a=bTest/example');
$DOMElementNode = $DOMDocumentNode-documentElement;
$DOMAttributeNode = $DOMElementNode-getAttributeNode('a');
$DOMTextNode = $DOMElementNode-firstChild;
var_dump($DOMDocumentNode, $DOMElementNode, $DOMAttributeNode, $DOMTextNode);
Expected result:
object(DOMDocument)#1 (34) {
[doctype]=
NULL
[implementation]=
string(22) (object value omitted)
[documentElement]=
string(22) (object value omitted)
[actualEncoding]=
NULL
[encoding]=
NULL
[xmlEncoding]=
NULL
[standalone]=
bool(true)
[xmlStandalone]=
bool(true)
[version]=
string(3) 1.0
[xmlVersion]=
string(3) 1.0
[strictErrorChecking]=
bool(true)
[documentURI]=
string(1) /
[config]=
NULL
[formatOutput]=
bool(false)
[validateOnParse]=
bool(false)
[resolveExternals]=
bool(false)
[preserveWhiteSpace]=
bool(true)
[recover]=
bool(false)
[substituteEntities]=
bool(false)
[nodeName]=
string(9) #document
[nodeValue]=
NULL
[nodeType]=
int(9)
[parentNode]=
NULL
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
NULL
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
object(DOMElement)#2 (17) {
[tagName]=
string(7) example
[schemaTypeInfo]=
NULL
[nodeName]=
string(7) example
[nodeValue]=
string(4) Test
[nodeType]=
int(1)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
string(22) (object value omitted)
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(7) example
[baseURI]=
string(1) /
[textContent]=
string(4) Test
}
Warning: var_dump(): Not yet implemented in /in/MXnGG on line 18
object(DOMAttr)#3 (20) {
[name]=
string(1) a
[specified]=
bool(true)
[value]=
string(1) b
[ownerElement]=
string(22) (object value omitted)
[schemaTypeInfo]=
NULL
[nodeName]=
string(1) a
[nodeValue]=
string(1) b
[nodeType]=
int(2)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
string(22) (object value omitted)
[firstChild]=
string(22) (object value omitted)
[lastChild]=
string(22) (object value omitted)
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
string(1) a
[baseURI]=
string(1) /
[textContent]=
string(1) b
}
object(DOMText)#4 (18) {
[wholeText]=
string(4) Test
[data]=
string(4) Test
[length]=
int(4)
[nodeName]=
string(5) #text
[nodeValue]=
string(4) Test
[nodeType]=
int(3)
[parentNode]=
string(22) (object value omitted)
[childNodes]=
NULL
[firstChild]=
NULL
[lastChild]=
NULL
[previousSibling]=
NULL
[attributes]=
NULL
[ownerDocument]=
string(22) (object value omitted)
[namespaceURI]=
NULL
[prefix]=
string(0)
[localName]=
NULL
Bug #63769 [Com]: file:// protocol does not support percent-encoded characters
Edit report at https://bugs.php.net/bug.php?id=63769edit=1
ID: 63769
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:file:// protocol does not support percent-encoded
characters
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
If you would create a file named
catalog%202.xml.
You would have wanted to access it via:
'file:///C:/temp/catalog%%25202.xml'
which as well does not work. I'm not doing a bug report here to be treated like
an idiot. I better suggest you piss completely off
instead of leaving such an idiotic comment. My 2 cents.
Previous Comments:
[2012-12-20 16:27:43] anon at anon dot anon
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not*
work.
Unfortunately it does work, if you create a file literally named
catalog%202.xml. PHP's behavior is broken but it's impossible to alter it
without breaking compatibility.
[2012-12-17 14:55:51] hanskrentel at yahoo dot de
I beg your pardon, but if both are perfectly valid filenames, the fs function
behaviour is broken (and not correct), because it does not work with both
perfectly valid filenames:
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not* work.
The request is to remove this shortcoming and have it work. I thought this was
clear from the initial report. Please let me know how I can further assist with
this.
[2012-12-15 11:12:14] a...@php.net
Since both catalog%202.xml and catalog 2.xml are perfectly valid filenames,
the fs function behaviour is correct. The user can decide where it's needed url
encoded and where it's not.
[2012-12-14 15:51:57] hanskrentel at yahoo dot de
Description:
Using a file-URI containing characters that are percent-encoded (one byte/octet
is encoded as a character triplet, e.g. Space - %20) do not work. The URI is
not properly decoded.
Consider the following file on disk:
c:\temp\catalog 2.xml
PHP is able to find it existing via:
is_file('file:///C:/temp/catalog 2.xml');
However, commonly that file is written as:
file:///C:/temp/catalog%202.xml
And using that filename in PHP via:
is_file('file:///C:/temp/catalog%202.xml');
gives FALSE.
(Example is a libxml catalog file, properly specified for libxml)
When you're looking into this, it might be worth to also look for + as encoding
for space - just not that this case gets overlooked.
Test script:
---
?php
touch($name = 'catalog 2.xml');
$uri = sprintf('file:///%s/%s', strtr(__DIR__, ['\\' = '/', ' ' = '%20']),
rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));
Expected result:
OK - file:///C:/temp/catalog%202.xml (1)
Actual result:
--
FAIL - file:///C:/temp/catalog%202.xml (1)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63769edit=1
[PHP-BUG] Req #63851 [NEW]: inet_ntop in WS2_32.dll has Windows Vista / Windows Server 2008 minimum require
From: hanskrentel at yahoo dot de Operating system: Win32 / XP PHP version: 5.5.0alpha2 Package: Win32API related Bug Type: Feature/Change Request Bug description:inet_ntop in WS2_32.dll has Windows Vista / Windows Server 2008 minimum require Description: I know that you don't want to support Windows XP any longer, but I think it's a pitty. When asked about that one only got the answer back that things must not break immediatly. My first reaction should have been dream on because as I now found out just starting on XP does fail immediately: inet_ntop entry point can not be found in WS2_32.dll - It has Windows Vista / Windows Server 2008 minimum requirements Please see http://social.msdn.microsoft.com/Forums/en- US/vcgeneral/thread/e40465f2-41b7-4243-ad33-15ae9366f4e6 on how to make that compatible, it might be of use. -- Edit bug report at https://bugs.php.net/bug.php?id=63851edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63851r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63851r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63851r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63851r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63851r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63851r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63851r=needscript Try newer version: https://bugs.php.net/fix.php?id=63851r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63851r=support Expected behavior: https://bugs.php.net/fix.php?id=63851r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63851r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63851r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63851r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63851r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63851r=dst IIS Stability: https://bugs.php.net/fix.php?id=63851r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63851r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63851r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63851r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63851r=mysqlcfg
Bug #63769 [Nab]: file:// protocol does not support percent-encoded characters
Edit report at https://bugs.php.net/bug.php?id=63769edit=1
ID: 63769
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:file:// protocol does not support percent-encoded
characters
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
I beg your pardon, but if both are perfectly valid filenames, the fs function
behaviour is broken (and not correct), because it does not work with both
perfectly valid filenames:
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not* work.
The request is to remove this shortcoming and have it work. I thought this was
clear from the initial report. Please let me know how I can further assist with
this.
Previous Comments:
[2012-12-15 11:12:14] a...@php.net
Since both catalog%202.xml and catalog 2.xml are perfectly valid filenames,
the fs function behaviour is correct. The user can decide where it's needed url
encoded and where it's not.
[2012-12-14 15:51:57] hanskrentel at yahoo dot de
Description:
Using a file-URI containing characters that are percent-encoded (one byte/octet
is encoded as a character triplet, e.g. Space - %20) do not work. The URI is
not properly decoded.
Consider the following file on disk:
c:\temp\catalog 2.xml
PHP is able to find it existing via:
is_file('file:///C:/temp/catalog 2.xml');
However, commonly that file is written as:
file:///C:/temp/catalog%202.xml
And using that filename in PHP via:
is_file('file:///C:/temp/catalog%202.xml');
gives FALSE.
(Example is a libxml catalog file, properly specified for libxml)
When you're looking into this, it might be worth to also look for + as encoding
for space - just not that this case gets overlooked.
Test script:
---
?php
touch($name = 'catalog 2.xml');
$uri = sprintf('file:///%s/%s', strtr(__DIR__, ['\\' = '/', ' ' = '%20']),
rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));
Expected result:
OK - file:///C:/temp/catalog%202.xml (1)
Actual result:
--
FAIL - file:///C:/temp/catalog%202.xml (1)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63769edit=1
[PHP-BUG] Bug #63769 [NEW]: file:// protocol does not support percent-encoded characters
From: hanskrentel at yahoo dot de
Operating system: Windows
PHP version: 5.4.9
Package: Streams related
Bug Type: Bug
Bug description:file:// protocol does not support percent-encoded characters
Description:
Using a file-URI containing characters that are percent-encoded (one
byte/octet
is encoded as a character triplet, e.g. Space - %20) do not work. The URI
is
not properly decoded.
Consider the following file on disk:
c:\temp\catalog 2.xml
PHP is able to find it existing via:
is_file('file:///C:/temp/catalog 2.xml');
However, commonly that file is written as:
file:///C:/temp/catalog%202.xml
And using that filename in PHP via:
is_file('file:///C:/temp/catalog%202.xml');
gives FALSE.
(Example is a libxml catalog file, properly specified for libxml)
When you're looking into this, it might be worth to also look for + as
encoding
for space - just not that this case gets overlooked.
Test script:
---
?php
touch($name = 'catalog 2.xml');
$uri = sprintf('file:///%s/%s', strtr(__DIR__, ['\\' = '/', ' ' =
'%20']), rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));
Expected result:
OK - file:///C:/temp/catalog%202.xml (1)
Actual result:
--
FAIL - file:///C:/temp/catalog%202.xml (1)
--
Edit bug report at https://bugs.php.net/bug.php?id=63769edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63769r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63769r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63769r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63769r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63769r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63769r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63769r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63769r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63769r=support
Expected behavior: https://bugs.php.net/fix.php?id=63769r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63769r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63769r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63769r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63769r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63769r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63769r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63769r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63769r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63769r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63769r=mysqlcfg
[PHP-BUG] Bug #63616 [NEW]: iterator_count loves SplFileObject too much (endless)
From: hanskrentel at yahoo dot de
Operating system: Windows
PHP version: 5.4.9
Package: SPL related
Bug Type: Bug
Bug description:iterator_count loves SplFileObject too much (endless)
Description:
For some reason not clear to me, using iterator_count with the iterator
interface
of SplFileObject (as well with SplTempFileObject) results in an endless
running
script.
Test script:
---
?php
$test = new SplFileObject(data://text/plain,1\n2);
$test-setFlags(SplFileObject::DROP_NEW_LINE);
echo Values: [, implode(', ', iterator_to_array($test)),
]\nCount: , iterator_count($test), \n;
?
-- OR --
?php
$test = new SplTempFileObject();
$test-setFlags(SplTempFileObject::DROP_NEW_LINE);
$test-fwrite(1\n2);
echo Values: [, implode(', ', iterator_to_array($test)),
]\nCount: , iterator_count($test), \n;
?
Expected result:
Values: [1, 2]
Count: 2
Actual result:
--
Values: [1, 2]
Count:
--
Edit bug report at https://bugs.php.net/bug.php?id=63616edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63616r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63616r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63616r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63616r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63616r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63616r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63616r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63616r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63616r=support
Expected behavior: https://bugs.php.net/fix.php?id=63616r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63616r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63616r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63616r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63616r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63616r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63616r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63616r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63616r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63616r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63616r=mysqlcfg
Req #63371 [Com]: Overriding method with an abstract method
Edit report at https://bugs.php.net/bug.php?id=63371edit=1
ID: 63371
Comment by: hanskrentel at yahoo dot de
Reported by:dagguh at gmail dot com
Summary:Overriding method with an abstract method
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Irrelevant
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
It works in Java, so why cannot it work in PHP?
Because PHP is PHP and Java is Java. So where to file the bug-report? Shouldn't
it
be reported as a bug at Java, because Java doesn't do it like PHP?
Previous Comments:
[2012-10-26 17:16:30] dagguh at gmail dot com
Description:
In Java you can override a method with an abstract one, but in PHP it results
in:
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
Test script:
---
class HttpNotFoundException extends RestResponseException {
public function getHttpStatusCode() {
// ...
}
}
abstract class RestResponseException extends IdentifiableException {
public abstract function getHttpStatusCode();
}
class IdentifiableException extends Exception {
// ...
}
// --- and here come the tests:
class HttpNotFoundExceptionTests extends RestResponseExceptionTests {
protected function getSystemUnderTest() {
return new HttpNotFoundException();
}
// ... tests logic specific to HttpNotFoundException
}
class RestResponseExceptionTests extends IdentifiableExceptionTests {
/**
* @return RestResponseException
*/
protected abstract function getSystemUnderTest();
// ... tests specific for RestResponseException, even though it is an
abstract class, it has some logic implemented and tests for that portion of
logic are specified here. It is important to note that while
getSystemUnderTest() method in IdentifiableExceptionTests expects
IdentifiableException, in RestResponseExceptionTests it expects
RestResponseException, which is a proper subclass of IdentifiableException
}
class IdentifiableExceptionTests extends PHPUnit_Framework_TestCase {
/**
* @return IdentifiableException
*/
protected function getSystemUnderTest() {
return new IdentifiableException();
}
//... tests IdentifiableException logic
}
Expected result:
I expect this code to work.
It works in Java, so why cannot it work in PHP?
Actual result:
--
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
--
Edit this bug report at https://bugs.php.net/bug.php?id=63371edit=1
Bug #63370 [Com]: ReflectionCLass::getDefaultProperties() return is incorrect for static properti
Edit report at https://bugs.php.net/bug.php?id=63370edit=1
ID: 63370
Comment by: hanskrentel at yahoo dot de
Reported by:dimzav at gmail dot com
Summary:ReflectionCLass::getDefaultProperties() return is
incorrect for static properti
Status: Open
Type: Bug
Package:Reflection related
Operating System: Win 7 x64
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
Please do not create a duplicate of the existing issue #51581. There was a
decision to not fix it for some reasons.
Also IMHO default values for global static class variables are as useful as
getting default values for other global variables.
You might have more luck in requesting a general reflection features for
variables - global ones, local ones, static ones and class static ones.
Previous Comments:
[2012-10-26 14:01:45] dimzav at gmail dot com
Description:
ReflectionCLass::getDefaultProperties() returns current value of static
property, not the default one. I can't add comment to
https://bugs.php.net/bug.php?id=51581 but it is evidently a bug and must be
fixed.
Test script:
---
class A
{
public static $a = 1;
}
A::$a = 2;
$reflectionCLass = new ReflectionClass('A');
$defaultProperties = $reflectionCLass-getDefaultProperties();
var_dump($defaultProperties);
Expected result:
Default value of $a static property is 1, it should be returned by
ReflectionCLass::getDefaultProperties() instead of current value.
Actual result:
--
C:\OpenServer\modules\php\PHP-5.3.18\php.exe temp.php
array(1) {
[a]=
int(2)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63370edit=1
Bug #63368 [Com]: Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone
Edit report at https://bugs.php.net/bug.php?id=63368edit=1 ID: 63368 Comment by: hanskrentel at yahoo dot de Reported by:mega dot venik at gmail dot com Summary:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone Status: Open Type: Bug Package:PHP options/info functions Operating System: Centos 6.3 PHP Version:5.3.18 Block user comment: N Private report: N New Comment: Why PHP doesn't read the timezone value from the global config file? Actually it does. Please double check the setting in the global php.ini configuration file. The FCGI PHP binary on your system might be configured to fetch a different global php.ini than the one you named: /etc/php.ini The error is likely on your end and configuration. Please double-check which php.ini is used with your fcgi configuration. Previous Comments: [2012-10-26 11:36:29] mega dot venik at gmail dot com correction [2012-10-26 11:35:05] mega dot venik at gmail dot com Description: There's a Centos6.3 system. Apache 2.2.15 + mod_fcgid + PHP 5.3.3 There's a problem with date.timezone value. It's mentioned in the global /etc/php.ini like this: date.timezone = Europe/Moscow And doesn't mentioned in user's local php.ini. As a result, I'm getting lot's of warnings like: Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead in ... Including the date.timezone parameter into the user's php.ini solves the problem, but I don't think, that it's the best solution. Why PHP doesn't read the timezone value from the global config file? Thanks! -- Edit this bug report at https://bugs.php.net/bug.php?id=63368edit=1
[PHP-BUG] Bug #63372 [NEW]: Namespace Declaration Missing Parse Error
From: hanskrentel at yahoo dot de
Operating system:
PHP version: 5.4.8
Package: Class/Object related
Bug Type: Bug
Bug description:Namespace Declaration Missing Parse Error
Description:
The following file namespace declaration:
namespace \Name;
Does not give a Parse Error. It's sister declaration:
namespace \Name {}
does.
Test script:
---
?php
namespace \Name;
Expected result:
Parse Error in Line 2 about an unexpected ; or T_NAMESPACE_SEPARATOR
Actual result:
--
Parser has no problem with the file at all.
Problems become only noticeable at runtime then.
--
Edit bug report at https://bugs.php.net/bug.php?id=63372edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63372r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63372r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63372r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63372r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63372r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63372r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63372r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63372r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63372r=support
Expected behavior: https://bugs.php.net/fix.php?id=63372r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63372r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63372r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63372r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63372r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63372r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63372r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63372r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63372r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63372r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63372r=mysqlcfg
Bug #63372 [Opn-Csd]: Namespace Declaration Missing Parse Error
Edit report at https://bugs.php.net/bug.php?id=63372edit=1
ID: 63372
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Namespace Declaration Missing Parse Error
-Status: Open
+Status: Closed
Type: Bug
-Package:Class/Object related
+Package:Scripting Engine problem
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
Solved. Thanks NikiC http://stackoverflow.com/a/13094151/367456
Previous Comments:
[2012-10-26 19:15:37] hanskrentel at yahoo dot de
Description:
The following file namespace declaration:
namespace \Name;
Does not give a Parse Error. It's sister declaration:
namespace \Name {}
does.
Test script:
---
?php
namespace \Name;
Expected result:
Parse Error in Line 2 about an unexpected ; or T_NAMESPACE_SEPARATOR
Actual result:
--
Parser has no problem with the file at all.
Problems become only noticeable at runtime then.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63372edit=1
Bug #62452 [Com]: Variable Aliasing does not work in Closure
Edit report at https://bugs.php.net/bug.php?id=62452edit=1
ID: 62452
Comment by: hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Variable Aliasing does not work in Closure
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Multiple
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
hi @laurence, thank's for taking the time to review it. If I write code like
unset($this);
it does not fatal error either (you can not destroy a object while you are
calling
it.).
Also I don't want to destroy the closure, I just want to re-use that variable.
Can't you just let the garbage collector do the dirty work?
Previous Comments:
[2012-07-02 07:03:19] larue...@php.net
you can not destroy a closure while you are calling it.
when you override $f in $f, zend vm try to destroy the closure $f, since the
refcout of it is 1.
try following :
$b = $f = function() use ($f) {
$f = function() {};
};
$f();
$f();
[2012-06-29 20:05:06] ni...@php.net
Verified on master.
[2012-06-29 19:53:22] hanskrentel at yahoo dot de
Description:
It's not possible to make use of variable aliasing in PHP when the alias is
used
within the use clause of a lambda function construct that is assigned to that
variable (recursion).
PHP denies to do what it is commanded with a Fatal error: Cannot destroy active
lambda function. But the function is not destroyed. It's just not that the
variable container contains the identifier of it.
I'd like to change that, and I don't want to waste another variable name. Also
I
don't understand how I can actually destroy something I should not have any
access
to from PHP userland.
Or if that is intended, please allow us to destroy the active lambda making the
function return NULL and continue to execute.
Test script:
---
$f = function() use ($f) {
$f = function() {echo hello};
};
$f();
$f();
Expected result:
hello
Actual result:
--
Fatal error: Cannot destroy active lambda function
--
Edit this bug report at https://bugs.php.net/bug.php?id=62452edit=1
[PHP-BUG] Bug #62452 [NEW]: Variable Aliasing does not work in Closure
From: hanskrentel at yahoo dot de
Operating system: Multiple
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Variable Aliasing does not work in Closure
Description:
It's not possible to make use of variable aliasing in PHP when the alias is
used
within the use clause of a lambda function construct that is assigned to
that
variable (recursion).
PHP denies to do what it is commanded with a Fatal error: Cannot destroy
active
lambda function. But the function is not destroyed. It's just not that the
variable container contains the identifier of it.
I'd like to change that, and I don't want to waste another variable name.
Also I
don't understand how I can actually destroy something I should not have any
access
to from PHP userland.
Or if that is intended, please allow us to destroy the active lambda making
the
function return NULL and continue to execute.
Test script:
---
$f = function() use ($f) {
$f = function() {echo hello};
};
$f();
$f();
Expected result:
hello
Actual result:
--
Fatal error: Cannot destroy active lambda function
--
Edit bug report at https://bugs.php.net/bug.php?id=62452edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62452r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62452r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62452r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62452r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62452r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62452r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62452r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62452r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62452r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62452r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62452r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62452r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62452r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62452r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62452r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62452r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62452r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62452r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62452r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62452r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62452r=mysqlcfg
Bug #54138 [Com]: DOMNode::getLineNo() doesn't return line number higher than 65535
Edit report at https://bugs.php.net/bug.php?id=54138edit=1
ID: 54138
Comment by: hanskrentel at yahoo dot de
Reported by:dmitrij at stepanov dot lv
Summary:DOMNode::getLineNo() doesn't return line number
higher than 65535
Status: Not a bug
Type: Bug
Package:XML Reader
Operating System: Windows 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The function DOMNode::getLineNo() is not able to return a line number higher
than 65535.
Test Script:
?php
$xml = ?xml version=\1.0\?root.str_repeat(\n, 65537)
.mixend/mix\nmixend/mix/root
;
echo dom_import_simplexml(
end(simplexml_load_string($xml)-xpath('//text()'))
)-getLineNo()
;
?
Expected result: 65537
Actual result: 65535
Summary: Reported back in 2007, upstream does not know how to fix this w/o
breaking stuff (binary compatibility).
It's also worth to mention that normally files with more than 65k lines aren't
written by hand so don't require that
type of functionality. Naturally this is subjective.
To fix this this requires a different upstream/patch of one of the underlying
libraries, e.g. libxml2. The debian
ticket has a patch.
https://mail.gnome.org/archives/xml/2007-October/msg2.html
http://lxr.php.net/xref/PHP_5_3/ext/dom/node.c#1955
http://lxr.php.net/xref/PHP_5_3/ext/libxml/php_libxml2.def#419
http://xmlsoft.org/html/libxml-tree.html#xmlGetLineNo
https://bugzilla.gnome.org/show_bug.cgi?id=676026
http://stackoverflow.com/a/11099693/367456
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445961
Previous Comments:
[2011-03-02 16:17:33] rricha...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Known limitation of libxml2
[2011-03-02 15:23:44] dmitrij at stepanov dot lv
Description:
DOMNode::getLineNo() doesn't return line number higher than 65535.
I assume that unsigned short is used for file line enumeration either in
XMLReader
or DOMNode internals.
Test script:
---
Try reading with XMLReader an XML file that has more than 65535 lines.
Then, when line nr. 65535 is reached, call XMLReader::expand()-getLineNo().
Expected result:
Correct line number.
Actual result:
--
65535 for lines, higher than 65525.
--
Edit this bug report at https://bugs.php.net/bug.php?id=54138edit=1
Req #62325 [Com]: Debug Backtrace gives no handle to anonymous functions
Edit report at https://bugs.php.net/bug.php?id=62325edit=1
ID: 62325
Comment by: hanskrentel at yahoo dot de
Reported by:anfurny22 at gmail dot com
Summary:Debug Backtrace gives no handle to anonymous
functions
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Windows
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I think the naming can be improved. Reference is quite generic, why not to
return
some reflection object if asked for?
Previous Comments:
[2012-06-14 17:25:19] anfurny22 at gmail dot com
Description:
Debug backtrace traditionally gives several pieces of information about the
call
stack, including file name, line number, and function name. However, with
anonymous functions it simply gives {closure}. This makes anonymous functions
received through debug_backtrace inaccesible through reflection because there
is
no reference to them.
I propose that debug_backtrace always provide an additional key reference
which
is a reference to the actual function. This will let the function be called or
provided to the reflection API.
Test script:
---
?PHP
$anon = function() {
$name = (debug_backtrace[0]['name']); // yields {closure}
$refl = new ReflectionFunction($name); // works great except with closures!
echo $refl-getDocComment(); // fails
}
$anon();
--
Edit this bug report at https://bugs.php.net/bug.php?id=62325edit=1
Bug #29206 [Com]: DOMDocument::LoadXML: Strict Standards: DOMDocument::loadXML(); is not static
Edit report at https://bugs.php.net/bug.php?id=29206edit=1 ID: 29206 Comment by: hanskrentel at yahoo dot de Reported by:tommy at vandervorst-bs dot nl Summary:DOMDocument::LoadXML: Strict Standards: DOMDocument::loadXML(); is not static Status: Not a bug Type: Bug Package:DOM XML related Operating System: Windows Server 2003 Standard PHP Version:5.0.0 Block user comment: N Private report: N New Comment: In PHP 5.3.10 Windows I have the problem that it's giving an error. In my eyes it does not violate strict standards as the PHP documentation for that function states that this function can be called statically as well. Could this be reviewed? Previous Comments: [2006-01-10 01:32:02] nfor...@php.net Surely the error message here is misleading. These functions/methods are clearly marked with ALLOW_STATIC... they definitely should not throw any sort of notice. Here's a patch to eliminate the message completely: http://noel.dotgeek.org/allow_static.patch [2004-07-16 12:43:39] rricha...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is not a pure static method as it is really an object method that is also allowed to be called statically, so under E_STRICT, that non-fatal message is issued. add $d-saveXML() and you will see the document was loaded. [2004-07-16 11:56:34] tommy at vandervorst-bs dot nl Description: The following code: $d = DOMDocument::loadXML(somexmlhere/here/xml/some); works perfectly well, but when setting PHP to report E_STRICT warnings: error_reporting(E_ALL|E_STRICT); It says: Strict Standards: Non-static method DOMDocument::loadXML() should not be called statically in [some script] on line [some line] which I think is incorrect, since DOMDocument::loadXML is (even according to the manual, http://nl2.php.net/manual/en/function.dom-domdocument-loadxml.php) a static function. Reproduce code: --- ?php error_reporting(E_ALL|E_STRICT); $d = DOMDocument::loadXML(somexmlhere/here/xml/some); ? Expected result: No error, this code is (in my eyes) perfectly valid. Actual result: -- Strict Standards: Non-static method DOMDocument::loadXML() should not be called statically in [some script] on line [some line] -- Edit this bug report at https://bugs.php.net/bug.php?id=29206edit=1
Bug #60569 [Csd-Asn]: Nullbyte truncates Exception $message.
Edit report at https://bugs.php.net/bug.php?id=60569edit=1 ID: 60569 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:Nullbyte truncates Exception $message. -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Fedora 14 PHP Version:5.3.8 Assigned To:iliaa Block user comment: N Private report: N New Comment: Re-open because it is not fixed. Previous Comments: [2012-03-14 10:52:47] hanskrentel at yahoo dot de Tested against PHP trunk Revision: 324199 (Windows), there still is truncation on the NULL char. $original = Null Char \0 Test.; echo Original Message..: , $original, \n; $e = new Exception($original); $processed = $e-getMessage(); echo Processed Message.: , $processed, \n; [2012-03-11 18:15:12] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-11 18:15:03] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=324112 Log: Fixed bug #60569 (Nullbyte truncates Exception $message). [2011-12-20 04:17:32] hanskrentel at yahoo dot de Description: When an Exception class is instantiated and a string contain a nullbyte character (\0) is used as $message, Exception::getMessage() returns a truncated string (the protected member Exception::$message is truncated as well). Looks like a duplicate of https://bugs.php.net/bug.php?id=50085 which outlined this as documentation problem. No idea why this is a documentation problem. Test script: --- $e = new Exception(test\0me); echo $e-getMessage(); Expected result: output (not displaying non-printable characters): testme Actual result: -- output (not displaying non-printable characters): test -- Edit this bug report at https://bugs.php.net/bug.php?id=60569edit=1
Bug #60569 [Csd]: Nullbyte truncates Exception $message.
Edit report at https://bugs.php.net/bug.php?id=60569edit=1 ID: 60569 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:Nullbyte truncates Exception $message. Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Fedora 14 PHP Version:5.3.8 Assigned To:iliaa Block user comment: N Private report: N New Comment: Tested against PHP trunk Revision: 324199 (Windows), there still is truncation on the NULL char. $original = Null Char \0 Test.; echo Original Message..: , $original, \n; $e = new Exception($original); $processed = $e-getMessage(); echo Processed Message.: , $processed, \n; Previous Comments: [2012-03-11 18:15:12] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-11 18:15:03] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=324112 Log: Fixed bug #60569 (Nullbyte truncates Exception $message). [2011-12-20 04:17:32] hanskrentel at yahoo dot de Description: When an Exception class is instantiated and a string contain a nullbyte character (\0) is used as $message, Exception::getMessage() returns a truncated string (the protected member Exception::$message is truncated as well). Looks like a duplicate of https://bugs.php.net/bug.php?id=50085 which outlined this as documentation problem. No idea why this is a documentation problem. Test script: --- $e = new Exception(test\0me); echo $e-getMessage(); Expected result: output (not displaying non-printable characters): testme Actual result: -- output (not displaying non-printable characters): test -- Edit this bug report at https://bugs.php.net/bug.php?id=60569edit=1
Bug #61312 [Com]: StdClass doesn't implement Traversable but can be traversed.
Edit report at https://bugs.php.net/bug.php?id=61312edit=1
ID: 61312
Comment by: hanskrentel at yahoo dot de
Reported by:le...@php.net
Summary:StdClass doesn't implement Traversable but can be
traversed.
Status: Closed
Type: Bug
Package:Class/Object related
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Same for array. It does not implement that interface but can be iterated over
in
a foreach loop.
If StdClass *had* the Traverseable interface and foreach would not work, then
I'd
say this is a bug.
See as well the documentation of foreach.
If you want to check foreach-ability: check for object or array *not*
Traversable.
Traversable is an internal type.
Previous Comments:
[2012-03-07 15:26:23] le...@php.net
Not a bug, really. All objects can be iterated. I had been up too late when I
filed the bug.
[2012-03-07 07:44:18] le...@php.net
Description:
StdClass does not implement the Traversable interface but can be iterated over
in
a foreach loop.
Test script:
---
$stdClass = new StdClass;
$stdClass-setUp = function () {
echo event[setUp] . . . \n;
};
$stdClass-tearDown = function () {
echo event[tearDown] . . . \n;
};
echo StdClass instanceof Traversable: ;
echo $stdClass instanceof Traversable
? Traversable\n
: Not traversable\n;
foreach ($stdClass as $key = $value) {
echo $key = ;
$value();
}
Expected result:
StdClass instanceof Traversable: Traversable
setUp = event[setUp] . . .
tearDown = event[tearDown] . . .
Actual result:
--
StdClass instanceof Traversable: Not traversable
setUp = event[setUp] . . .
tearDown = event[tearDown] . . .
--
Edit this bug report at https://bugs.php.net/bug.php?id=61312edit=1
Bug #60601 [Com]: ReflectionMethod::InvokeArgs not work normally in function
Edit report at https://bugs.php.net/bug.php?id=60601edit=1
ID: 60601
Comment by: hanskrentel at yahoo dot de
Reported by:joelp at email dot cz
Summary:ReflectionMethod::InvokeArgs not work normally in
function
Status: Open
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is not a bug but a problem how you pass the arguments.
As the warning says, you need to give a variable, but you give values:
$variables = array (one62,two62);
Instead give variables:
$var1 = one62;
$var2 = two62;
$variables = array ($var1, $var2);
Hope this is helpful.
Previous Comments:
[2011-12-23 13:56:49] joelp at email dot cz
Description:
If I try to use ReflectionMethod::InvokeArgs after using function array_unshift
inside of user function, this return me this:
Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference,
value given in /www/transaction_test.php on line 132
Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132
Stack trace: #0 /www/transaction_test.php(132):
ReflectionMethod-invokeArgs(Object(mysqli_stmt), Array) #1
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array,
'ss') #2 {main} thrown in /www/transaction_test.php on line 132
If I try run it out of user function. Everything is OK.
Test script:
---
function test_case_function ($sql,$variables,$vars) {
$mysqli = new mysqli(db_server, db_user_name, db_user_passwd, db_name);
$mysqli-query(SET NAMES 'utf8') or die ('Could not set Charset');
$mysqli-autocommit(FALSE);
array_unshift($variables,$vars);
if ($stm=$mysqli-prepare($sql)) {
$method= new ReflectionMethod('mysqli_stmt','bind_param');
$method-invokeArgs($stm,$variables);
}
$stm-execute();
printf(%d Row inserted\n, $stm-affected_rows);
$mysqli-commit();
$stm-close();
$mysqli-close();
}
$sql = INSERT INTO `test_table` (`time`,`one`,`two`) VALUES (NOW(),?,?);;
$vars = 'ss';
$variables = array (one62,two62);
test_case_function($sql,$variables,$vars);
Expected result:
Script print 1 Row inserted
Actual result:
--
Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference,
value given in /www/transaction_test.php on line 132
Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132
Stack trace: #0 /www/transaction_test.php(132):
ReflectionMethod-invokeArgs(Object(mysqli_stmt), Array) #1
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array,
'ss') #2 {main} thrown in /www/transaction_test.php on line 132
--
Edit this bug report at https://bugs.php.net/bug.php?id=60601edit=1
Req #60581 [Com]: Russia have no summer/winter offset from 2011
Edit report at https://bugs.php.net/bug.php?id=60581edit=1
ID: 60581
Comment by: hanskrentel at yahoo dot de
Reported by:ion at 66 dot ru
Summary:Russia have no summer/winter offset from 2011
Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: ubuntu
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Which version of the timezonedb are you using in that example?
see as well http://pecl.php.net/package/timezonedb
Previous Comments:
[2011-12-20 22:33:25] ion at 66 dot ru
Description:
Russia have no summer/winter offset from 2011
Test script:
---
$winter = new DateTime('2012-12-21', new DateTimeZone('Europe/Moscow'));
$summer = new DateTime('2012-04-21', new DateTimeZone('Europe/Moscow'));
$tz[winter]= ($winter-getOffset())/60/60;
$tz[summer]= ($summer-getOffset())/60/60;
$tz[diff]=$tz[summer]-$tz[winter];
echo $tz[diff];
Expected result:
0
Actual result:
--
1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60581edit=1
Bug #60574 [Com]: range() returns array of integers when arguments are numeric strings
Edit report at https://bugs.php.net/bug.php?id=60574edit=1
ID: 60574
Comment by: hanskrentel at yahoo dot de
Reported by:login dot naitsirch at arcor dot de
Summary:range() returns array of integers when arguments are
numeric strings
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is already documented:
4.1.0 to 4.3.2 In PHP versions 4.1.0 through 4.3.2, range() sees numeric
strings
as strings and not integers. Instead, they will be used for character
sequences.
For example, 4242 is treated as 4.
Previous Comments:
[2011-12-20 11:39:15] login dot naitsirch at arcor dot de
Description:
Hi.
I think the 'range()' function should return an array with strings, if the
'start' and 'limit' arguments are numeric strings. Otherwise it should be
mentioned in the documentation.
Test script:
---
?php
var_dump(range('0', '9'));
Expected result:
array(10) {
[0]= string(1) 0
[1]= string(1) 1
[2]= string(1) 2
[3]= string(1) 3
[4]= string(1) 4
[5]= string(1) 5
[6]= string(1) 6
[7]= string(1) 7
[8]= string(1) 8
[9]= string(1) 9
}
Actual result:
--
array(10) {
[0]= int(0)
[1]= int(1)
[2]= int(2)
[3]= int(3)
[4]= int(4)
[5]= int(5)
[6]= int(6)
[7]= int(7)
[8]= int(8)
[9]= int(9)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60574edit=1
[PHP-BUG] Bug #60620 [NEW]: ReflectionFunction Internal Error provocation
From:
Operating system: win
PHP version: 5.3.8
Package: Reflection related
Bug Type: Bug
Bug description:ReflectionFunction Internal Error provocation
Description:
Normally Instantiation fails (ReflectionException):
$test = new ReflectionFunction('');
However this can be fooled:
$obj = new stdClass();
$test = new ReflectionFunction($obj);
echo $test;
The echo line triggers a fatal error then:
Fatal error: ReflectionFunction::__toString(): Internal error: Failed to
retrieve the reflection object
Before that happens there is a slightly misworded warning ahead:
Warning: ReflectionFunction::__construct() expects parameter 1 to be
string,
object given
Misworded in the sense that it's possible objects with __toString() and
closures.
Probably something in the logic inside the constructor is not right. It
would be
good if in such cases an ReflectionException is thrown on instantiation.
Test script:
---
$obj = new stdClass();
$test = new ReflectionFunction($obj);
echo $test;
Expected result:
ReflectionException
Actual result:
--
Fatal Error
--
Edit bug report at https://bugs.php.net/bug.php?id=60620edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60620r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60620r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60620r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60620r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60620r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60620r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60620r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60620r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60620r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60620r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60620r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60620r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60620r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60620r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60620r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60620r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60620r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60620r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60620r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60620r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60620r=mysqlcfg
Req #60364 [Com]: Implement ability to recover from fatal errors in eval()'d code
Edit report at https://bugs.php.net/bug.php?id=60364edit=1
ID: 60364
Comment by: hanskrentel at yahoo dot de
Reported by:zyss at mail dot zp dot ua
Summary:Implement ability to recover from fatal errors in
eval()'d code
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: All
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Why specific for eval and not include and/or overal?
This could be solved more straight forward solved by making fatal errors an
Exception in PHP, like suggested in #28331 (which names eval in a comment as a
use-case).
Previous Comments:
[2011-11-23 13:27:35] zyss at mail dot zp dot ua
Description:
Sometimes eval() is used as a way to execute PHP code within a shell (legal
remote access for debugging purposes) or to execute code compiled to PHP from
higher-level scripting language or the code stored in the database etc.
The common problem is that a call of non-existing function (or object
instantiation) results in termination of the whole script, not just eval'd code.
I think that it's not correct in such cases.
The obvious way to implement it would be adding flags to eval() function (as a
second argument) one of which could indicate that eval() should not terminate
the script but just return an error or raise an exception.
Such flags could be:
EVAL_FATAL_DIE// current behavior
EVAL_FATAL_ERROR // return FALSE
EVAL_FATAL_EXCEPTION // raise an exception of a predefined class (e.g.
EvalException)
Test script:
---
try {
eval('non_existing_function()', EVAL_FATAL_EXCEPTION);
}
catch (EvalException $e) {
Logger::log('Error in eval\'d code', $e);
}
Expected result:
Exception being logged and script continued its execution.
Actual result:
--
Fatal error: Call to undefined function non_existing_function() in ... :
eval()'d code(1) on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60364edit=1
[PHP-BUG] Bug #60569 [NEW]: Nullbyte truncates Exception $message.
From: Operating system: Fedora 14 PHP version: 5.3.8 Package: Scripting Engine problem Bug Type: Bug Bug description:Nullbyte truncates Exception $message. Description: When an Exception class is instantiated and a string contain a nullbyte character (\0) is used as $message, Exception::getMessage() returns a truncated string (the protected member Exception::$message is truncated as well). Looks like a duplicate of https://bugs.php.net/bug.php?id=50085 which outlined this as documentation problem. No idea why this is a documentation problem. Test script: --- $e = new Exception(test\0me); echo $e-getMessage(); Expected result: output (not displaying non-printable characters): testme Actual result: -- output (not displaying non-printable characters): test -- Edit bug report at https://bugs.php.net/bug.php?id=60569edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60569r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60569r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60569r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60569r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60569r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60569r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60569r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60569r=needscript Try newer version: https://bugs.php.net/fix.php?id=60569r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60569r=support Expected behavior: https://bugs.php.net/fix.php?id=60569r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60569r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60569r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60569r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60569r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60569r=dst IIS Stability: https://bugs.php.net/fix.php?id=60569r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60569r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60569r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60569r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60569r=mysqlcfg
Bug #55222 [Ver]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222edit=1 ID: 55222 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:Fatal Error disappears when using paranthesis Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I assume you want to say that the linked answer explicitly explains the problem. Should we make use of this feature when programming PHP or not? Previous Comments: [2011-07-29 09:56:38] cataphr...@php.net See http://stackoverflow.com/questions/6726589/parentheses-altering-semantics-of-function-call-result/6732876#6732876 [2011-07-27 16:34:24] hanskrentel at yahoo dot de I can only remind again that the first comment from php.net obviously misread this report. I am _missing_ the fatal error. [2011-07-19 08:10:56] hanskrentel at yahoo dot de Actually I'm concerned that reset( (get_array()) ); does _not_ give a fatal error. This contradicts the last comment There's really no way to get around that [getting a fatal error]. Why does it not give a fatal error? There is no variable. [2011-07-18 22:21:36] ahar...@php.net reset() requires a variable that can be passed by reference. There's really no way to get around that, hence the fatal error. [2011-07-17 16:52:26] hanskrentel at yahoo dot de within = without in the description. 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 https://bugs.php.net/bug.php?id=55222 -- Edit this bug report at https://bugs.php.net/bug.php?id=55222edit=1
Bug #55222 [Bgs]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222edit=1
ID: 55222
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Fatal Error disappears when using paranthesis
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I can only remind again that the first comment from php.net obviously misread
this report.
I am _missing_ the fatal error.
Previous Comments:
[2011-07-19 08:10:56] hanskrentel at yahoo dot de
Actually I'm concerned that
reset( (get_array()) );
does _not_ give a fatal error. This contradicts the last comment There's
really
no way to get around that [getting a fatal error].
Why does it not give a fatal error? There is no variable.
[2011-07-18 22:21:36] ahar...@php.net
reset() requires a variable that can be passed by reference. There's really no
way
to get around that, hence the fatal error.
[2011-07-17 16:52:26] hanskrentel at yahoo dot de
within = without in the description.
[2011-07-17 16:51:34] hanskrentel at yahoo dot de
Description:
PHP 5.3 is giving me nice, sound FATAL ERRORS when using functions like reset()
within a variable. However it looks like that it's not always taken care of
that consequentially.
I don't even get a strict standards warning even.
Test script:
---
?php
error_reporting(~0);
function get_array() {
return Array(1);
}
function foo() {
// return reset( (get_array()?:null) );
// ^Fatal error: Only variables can be passed by reference
return reset( (get_array()) );
// ^Only? This one works OK
}
foo();
Expected result:
Fatat error.
Actual result:
--
All fine.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55222edit=1
Bug #55222 [Bgs]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222edit=1
ID: 55222
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Fatal Error disappears when using paranthesis
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Actually I'm concerned that
reset( (get_array()) );
does _not_ give a fatal error. This contradicts the last comment There's
really
no way to get around that [getting a fatal error].
Why does it not give a fatal error? There is no variable.
Previous Comments:
[2011-07-18 22:21:36] ahar...@php.net
reset() requires a variable that can be passed by reference. There's really no
way
to get around that, hence the fatal error.
[2011-07-17 16:52:26] hanskrentel at yahoo dot de
within = without in the description.
[2011-07-17 16:51:34] hanskrentel at yahoo dot de
Description:
PHP 5.3 is giving me nice, sound FATAL ERRORS when using functions like reset()
within a variable. However it looks like that it's not always taken care of
that consequentially.
I don't even get a strict standards warning even.
Test script:
---
?php
error_reporting(~0);
function get_array() {
return Array(1);
}
function foo() {
// return reset( (get_array()?:null) );
// ^Fatal error: Only variables can be passed by reference
return reset( (get_array()) );
// ^Only? This one works OK
}
foo();
Expected result:
Fatat error.
Actual result:
--
All fine.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55222edit=1
[PHP-BUG] Bug #55222 [NEW]: Fatal Error disappears when using paranthesis
From:
Operating system: Linux
PHP version: 5.3.6
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Fatal Error disappears when using paranthesis
Description:
PHP 5.3 is giving me nice, sound FATAL ERRORS when using functions like
reset() within a variable. However it looks like that it's not always taken
care of that consequentially.
I don't even get a strict standards warning even.
Test script:
---
?php
error_reporting(~0);
function get_array() {
return Array(1);
}
function foo() {
// return reset( (get_array()?:null) );
// ^Fatal error: Only variables can be passed by
reference
return reset( (get_array()) );
// ^Only? This one works OK
}
foo();
Expected result:
Fatat error.
Actual result:
--
All fine.
--
Edit bug report at https://bugs.php.net/bug.php?id=55222edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55222r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55222r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55222r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55222r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55222r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55222r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55222r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55222r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55222r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55222r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55222r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55222r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55222r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55222r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55222r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55222r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55222r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55222r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55222r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55222r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55222r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55222r=trysnapshot54
Bug #55222 [Opn]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222edit=1
ID: 55222
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Fatal Error disappears when using paranthesis
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
within = without in the description.
Previous Comments:
[2011-07-17 16:51:34] hanskrentel at yahoo dot de
Description:
PHP 5.3 is giving me nice, sound FATAL ERRORS when using functions like reset()
within a variable. However it looks like that it's not always taken care of
that consequentially.
I don't even get a strict standards warning even.
Test script:
---
?php
error_reporting(~0);
function get_array() {
return Array(1);
}
function foo() {
// return reset( (get_array()?:null) );
// ^Fatal error: Only variables can be passed by reference
return reset( (get_array()) );
// ^Only? This one works OK
}
foo();
Expected result:
Fatat error.
Actual result:
--
All fine.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55222edit=1
Bug #36705 [Com]: Location header results in duplicate Status header ([f]cgi only)
Edit report at http://bugs.php.net/bug.php?id=36705edit=1
ID: 36705
Comment by: hanskrentel at yahoo dot de
Reported by: alisencer at gmail dot com
Summary: Location header results in duplicate Status header
([f]cgi only)
Status: Closed
Type: Bug
Package: Unknown/Other Function
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
This was reported to work for 5.3.0 I was curious how that behaves on
5.2.x and did run a test. It works, here are the details:
PHP 5.2.6 (cgi-fcgi) (built: May 2 2008 18:02:06)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.0RC4-dev, Copyright (c) 2002, 2003, 2004, 2005,
2006, 2007, by Derick Rethans
Status: 301
Location: http://www.example.org
Content-type: text/html
Previous Comments:
[2008-04-13 23:36:23] bj...@php.net
bj...@lindsay:~$ ./php/5.3/sapi/cgi/php-cgi
?php
header(Status: 301);
header(Location: http://www.example.org;);
?
X-Powered-By: PHP/5.3.0-dev
Status: 301
Location: http://www.example.org
Content-type: text/html; charset=utf-8
Works fine now...
[2006-12-07 20:21:29] chris at vault5 dot com
This bug is filed against FreeBSD but it is certainly not limited to
that OS.
Using the Microsoft IIS FastCGI ISAPI extension this issue occurs on
IIS, too.
[2006-05-03 18:37:20] phpbugs at thequod dot de
As far as I remember from looking around because of the
already mentioned bogus bug
http://bugs.php.net/bug.php?id=33225:
The CGI spec says that there should only be one Status
header.
In my humble opinion, PHP should take care of sending only
one status header.
In the case of Location: any existing one should get
overwritten and not added.
[2006-04-22 07:57:34] bryan at b1t5 dot com
The most effective workaround is to just edit mod_fastcgi.c
if (strcasecmp(name, Status) == 0) {
int statusValue = strtol(value, NULL, 10);
if (hasStatus) {
/* comment out the braindead line below */
/* goto DuplicateNotAllowed;*/
}
if (statusValue 0) {
fr-parseHeader = SCAN_CGI_BAD_HEADER;
return ap_psprintf(r-pool, invalid Status '%s',
value);
}
hasStatus = TRUE;
r-status = statusValue;
r-status_line = ap_pstrdup(r-pool, value);
continue;
}
apache doesn't care how many times you set r-status. Set it once,
twice, 500 times even -- it doesn't matter cuz r is just a struct you
fill up before calling ap_send_http_header(r)
[2006-03-13 03:55:42] judas dot iscariote at gmail dot com
as an effective workaround to this problem, you can use PEAR HTTP_Header
class.
hint : method sendStatusCode()
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/bug.php?id=36705
--
Edit this bug report at http://bugs.php.net/bug.php?id=36705edit=1
#37350 [Com]: realpath() doesn't canonicalize drive letter case
ID: 37350
Comment by: hanskrentel at yahoo dot de
Reported By: k95vz5f02 at sneakemail dot com
Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.1.4
New Comment:
within the windows OS there is no difference between cAsE in filenames,
a solution might be to read out the actual filename from the system and
return it by realpath.
but this won't be a valid solution afterall: next to case ignorance,
there are two filenames for a file as well: the long and the short
(8.3) one (since win/32/95 or FAT 32). so i guess a comparison will
fail in that case anyway.
additionally, for me another problem occurs:
c:\windows is a directory and could be name as c:\windows\ as well (in
my opinion it even should but that's my personal opinion anyway).
since for me there is no logical correct solution for this problem
anyway I would suggest to handle the windows filesystem more similar to
the *nix one, that meaning using / instead of \ for example to point to
directories with the needed / at the end. additionally, a virtual root
might be good idea as well sothat c:\windows would be /c:/windows/
afterall. this would help developers to create better cross platform
code. this might be already discussed somewhere else maybe.
Previous Comments:
[2006-05-07 18:41:58] [EMAIL PROTECTED]
Realpath is also used internally for f.e. include_once, so this should
be looked into.
[2006-05-07 18:08:28] k95vz5f02 at sneakemail dot com
Description:
The realpath function doesn't canonicalize the case of the drive letter
on Windows (and possibly on certain other platforms).
For example:
realpath('C:\WINDOWS') returns 'C:\WINDOWS'
but realpath('c:\WINDOWS') returns 'c:\WINDOWS'
(note the different case of the 'C:')
Hence comparing realpaths cannot reliably be used to check that two
files are the same on Windows.
Reproduce code:
---
echo (realpath('C:\WINDOWS')==realpath('c:\WINDOWS')) ? true :
false;
Expected result:
true
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/?id=37350edit=1
#36290 [Com]: tempnam() creates file on wrong drive
ID: 36290
Comment by: hanskrentel at yahoo dot de
Reported By: info at silisoftware dot com
Status: No Feedback
Bug Type: Filesystem function related
Operating System: Windows XP Pro SP2
PHP Version: 4.4.2
New Comment:
I just checked this out on PHP Version 5.1.2 and the behavior for me is
the same, so this was not fixed.
reproduced with:
$tempname = tempnam('', 'foo');
echo $tempname.'br';
echo realpath($tempname).'br';
output in my case:
\foo5E0.tmp
d:\foo5E0.tmp
d:\ is not my tempdir
anyway this function behaves inconsisten per default as discribben in
the current online documentaion:
Creates a file with a unique filename in the specified directory. If
the directory does not exist, tempnam() may generate a file in the
system's temporary directory, and return the name of that.
http://www.php.net/manual/en/function.tempnam.php
so the behavior is correct per definition but useless and i guess not
intended.
Previous Comments:
[2006-02-13 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-02-05 10:31:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-05 02:19:00] info at silisoftware dot com
Description:
tempnam() returns a temp filename, and creates the file. However, it
creates it on the wrong drive. For example:
$tempname = tempnam('', 'foo');
echo $tempname.'br';
echo realpath($tempname).'br';
This outputs:
\foo49.tmp
e:\foo49.tmp
Notice the returned filename has no drive letter. The file is created
(to prevent race condition) in C:\ but realpath() resolves that to E:\
(the last drive letter of physical harddrives in this system).
For reference:
getenv('TMP')== 'C:\WINDOWS\TEMP'
getenv('TMPDIR') == ''
Reproduce code:
---
$tempname = tempnam('', 'foo');
echo $tempname.'br';
echo realpath($tempname).'br';
Expected result:
c:\foo49.tmp
c:\foo49.tmp
Actual result:
--
\foo49.tmp
e:\foo49.tmp
--
Edit this bug report at http://bugs.php.net/?id=36290edit=1
#33831 [NEW]: include does not work within class() {}
From: hanskrentel at yahoo dot de
Operating system: win32
PHP version: 4.4.0
PHP Bug Type: Feature/Change Request
Bug description: include does not work within class() {}
Description:
the include() and require() statements do not work within the class() {}
block. that's really a pitty, because it would be nice to put some
function out of the class main file to make it easier to maintain larger
class files.
this is not new. but there is a new scenario not in the database:
---
this seems to be a real bug in some cases. even if include works within a
function statement within a class statement, it can not close this
functions code-block even if it does. so this does not works as expected
as stated by ernest at vogelsinger dot at.
you get no error in that kind of code but the function is not defined at
all:
class_a.php:
?
class A
{
function B ()
{
include('class_a_c_method_tricky.php');
/* code of function Ctricky */
}
}
?
class_a_c_method_tricky.php:
?
/* code of function B */
}
function C ()
{
/* code of function C */
}
function Ctricky()
{
?
the include is done (no error), but class A-C() is not defined. something
is messed up here.
Reproduce code:
---
class.foo.php:
?
class foo() {
function foo() {
$this-that = 'whatever';
}
include('class.foo-functions.php');
}
$c = new foo();
$c-fob();
?
class.foo-functions.php:
?
function fob() {
echo 'fob';
}
?
Expected result:
fob
Actual result:
--
Parse error: parse error, unexpected T_REQUIRE, expecting T_OLD_FUNCTION
or T_FUNCTION or T_VAR or '}' in [...]
--
Edit bug report at http://bugs.php.net/?id=33831edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33831r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33831r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33831r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33831r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33831r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33831r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33831r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33831r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33831r=support
Expected behavior: http://bugs.php.net/fix.php?id=33831r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33831r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33831r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33831r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33831r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33831r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33831r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33831r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33831r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33831r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33831r=mysqlcfg
