#49647 [NEW]: DOMUserData does not exist
From: ashn...@php.net Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Reflection related Bug description: DOMUserData does not exist Description: Reflection actitivy against a child of DOMElement can result in: "ReflectionException: Class DOMUserData does not exist" presumably due to dom_node_get_user_data in ext/dom/node.c. The actual class does not appear to exist, although the method shows it as a datatype for a parameter. Reproduce code: --- getName(); ?> Expected result: DOMUserData Actual result: -- ReflectionException: Class DOMUserData does not exist -- Edit bug report at http://bugs.php.net/?id=49647&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49647&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49647&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49647&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49647&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49647&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49647&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49647&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49647&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49647&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49647&r=support Expected behavior: http://bugs.php.net/fix.php?id=49647&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49647&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49647&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49647&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49647&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49647&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49647&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49647&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49647&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49647&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49647&r=mysqlcfg
Bug #55634 [Com]: ./configure does not fail if invalid option is used
Edit report at https://bugs.php.net/bug.php?id=55634&edit=1 ID: 55634 Comment by: ashn...@php.net Reported by:cwei...@php.net Summary:./configure does not fail if invalid option is used Status: Open Type: Bug Package:*Configuration Issues PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Perhaps a BC compromise here would be to at least *also* echo to stderr, while leaving the existing echo to stdout in place? Previous Comments: [2011-09-07 22:28:17] f...@php.net I'm not saying this behaviour is wrong or right, I've been bitten by this already myself, but I do think that could be considered a BC break, as I remember it always being like that, although I'm only 100% sure on 5.2+ [2011-09-07 13:17:55] cwei...@php.net Description: When using ./configure --with-foo, configure tells me at the end: > Notice: Following unknown configure options were used: > --with-foo There are two problems: - This problem is echoed to stdout, not stderr where capturing it would be possible - The exit code is still 0, although I clearly issued a wrong option. In the end I cannot figure out if the configure run was *fully* successful. Expected result: 1. config option errors echoed to stderr 2. exit code of configure script != 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55634&edit=1
Bug #63917 [Com]: SplObjectStorage: Iteration of all the objects is not possible after detach()
Edit report at https://bugs.php.net/bug.php?id=63917&edit=1
ID: 63917
Comment by: ashn...@php.net
Reported by:LastDragon at yandex dot ru
Summary:SplObjectStorage: Iteration of all the objects is
not possible after detach()
Status: Open
Type: Bug
Package:SPL related
Operating System: all
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
Are the "Expected" and "Actual" blocks reversed on this initial report? I came
searching for an SplObjectStorage bug where attempting to foreach() it and
detach all its members was failing to detach the final member. This bug report
looks like it reports exactly that, if you switch the Expected and Actual
blocks.
In my case, a foreach() around one SplObjectStorage object that performs a
detach() per member is finishing the foreach() loop while leaving one member
still attached. I can do a second foreach() on the SplObjectStorage object,
and this time it does see the remaining one member and detaches it
successfully. I suspect, as this bug report seems to specifically say, that
the detach() operation in the foreach() is causing an off-by-one error or is
implicitly calling one of the Iterator methods in a way that throws off the
foreach()'s Iterator steps.
Previous Comments:
[2013-01-06 11:25:18] LastDragon at yandex dot ru
Description:
Iteration of all the objects is not possible after the detach method was called.
Test script:
---
attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
var_dump($s->count());
foreach ($s as $v) {
var_dump($v);
$s->detach($v);
}
var_dump($s->count());
Expected result:
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(1)
Actual result:
--
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#3 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63917&edit=1
Bug #63917 [PATCH]: SplObjectStorage: Iteration of all the objects is not possible after detach()
Edit report at https://bugs.php.net/bug.php?id=63917&edit=1
ID: 63917
Patch added by: ashn...@php.net
Reported by:LastDragon at yandex dot ru
Summary:SplObjectStorage: Iteration of all the objects is
not possible after detach()
Status: Open
Type: Bug
Package:SPL related
Operating System: all
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63917.phpt
Revision: 1357744702
URL:
https://bugs.php.net/patch-display.php?bug=63917&patch=bug63917.phpt&revision=1357744702
Previous Comments:
[2013-01-09 06:05:45] LastDragon at yandex dot ru
> Are the "Expected" and "Actual" blocks reversed on this initial report?
Yes. Sorry. Unfortunately I cannot edit this blocks :(
[2013-01-08 21:05:06] ashn...@php.net
Are the "Expected" and "Actual" blocks reversed on this initial report? I came
searching for an SplObjectStorage bug where attempting to foreach() it and
detach all its members was failing to detach the final member. This bug report
looks like it reports exactly that, if you switch the Expected and Actual
blocks.
In my case, a foreach() around one SplObjectStorage object that performs a
detach() per member is finishing the foreach() loop while leaving one member
still attached. I can do a second foreach() on the SplObjectStorage object,
and this time it does see the remaining one member and detaches it
successfully. I suspect, as this bug report seems to specifically say, that
the detach() operation in the foreach() is causing an off-by-one error or is
implicitly calling one of the Iterator methods in a way that throws off the
foreach()'s Iterator steps.
[2013-01-06 11:25:18] LastDragon at yandex dot ru
Description:
Iteration of all the objects is not possible after the detach method was called.
Test script:
---
attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
var_dump($s->count());
foreach ($s as $v) {
var_dump($v);
$s->detach($v);
}
var_dump($s->count());
Expected result:
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(1)
Actual result:
--
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#3 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63917&edit=1
