Description: ------------ As discussed on the PEAR-DEV mailinglist a week ago in various, it is possible to use PEAR in PHP5 with E_STRICT error reporting turned on. This is done by muting the E_STRICT warnings generated by PEAR. However, when using Xdebug (and possibly other opcode caches), compile-time E_STRICT warnings cannot be muted in this way. This is by design (see http://xcache.lighttpd.net/ticket/127 ). PEAR.php triggers two compile-time E_STRICT errors. This is caused by two occurences of "$a = &new" in PEAR::raiseError(). This change request is about modifying the code in a way so that it does not trigger these errors. The attached patch tries to solve this problem by using eval() to hide the offending & from PHP5. The "= &new" construct is still used in PHP4 in order to return the object by reference. This isn't necessary in PHP5, and to avoid the slight performance hit (if any?) caused by eval(), PHP5 takes a different code path. A less complex (but possibly slightly slower) approach is to make PHP4 and PHP5 share the same code path and let them both use eval(). Also the patch contains a change to the PEAR_Error constructor that removes the stack frame introduced by eval(). Personally I consider this unnecessary. I only do it to be as BC as possible. But it probably wont cause many BC problems if this is part of the patch is omitted. There were concerns on the mailinglist about whether changes like this would too be risky WRT introducing BC breaks compared to the somewhat esoteric problem it is trying to solve. To the best of my knowledge, the change is 100% BC in PHP4. In PHP5, the contained backtrace is slightly different (I doubt this is relevant - if it /is/ considered relevant, it can be fixed by making PHP5 follow the eval() code path), and of course it now does not trigger the E_STRICT errors. I have tested the patch with both PHP4 and PHP5, though not intensively. If you consider this change too risky, I understand. But I hope that you at least will take a look at it :-)

the & may not even be necessary. the constructor for PEAR_Error passes $this to a callback if defined, but the only way this could mess anything up is if the PEAR_Error object passed to the callback is compared with === to the PEAR_Error object returned from raiseError Pending testing, removing & will be in 1.7.0. I am not going to use an eval() hack, sorry.

Omitting the & could also cause problems, if the error class isn't PEAR_Error but some other class that does something like "$some_global_array[] = &$this;" it its constructor.

I tried the patch in the context of the Symfony framework. Inserted the following block of test code inside a Symfony action class: ========= require_once "PEAR.php"; function test() { return PEAR::raiseError( "oops", 1 ); } $t = test(); if ( PEAR::isError( $t ) ) { echo $t->getMessage(); } die; =========== We still E_STRICT warnings: Strict standards: Non-static method PEAR::raiseError() should not be called statically in J:\htdocs\www\symfony\apps\services\modules\order\actions\actions.class.php on line 44 Strict standards: Non-static method PEAR::getStaticProperty() should not be called statically, assuming $this from incompatible context in J:\htdocs\PEAR\PEAR.php on line 875 Strict standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in J:\htdocs\www\symfony\apps\services\modules\order\actions\actions.class.php on line 50 Strict standards: is_a(): Deprecated. Please use the instanceof operator in J:\htdocs\PEAR\PEAR.php on line 281

ignatius, you can mute those errors using a custom error handler (see http://article.gmane.org/gmane.comp.php.pear.devel/43559 where this approach has been discussed). This bug report concerns a particular type of E_STRICT errors that cannot be muted using a custom error handler.

Thanks Well, muting: @PEAR::raiseError( "oops", 1 ); and @PEAR::isError does the trick, and notices do not appear any longer with Xdebug.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. sorry, the eval is not a solution.