Description: ------------ I know that the Mail package in general is not E_STRICT compliant. However, we run with E_STRICT error-reporting and let our custom error-handler mute strict warnings from third-party code (PEAR etc.). This works pretty good, except when using an opcode cache like e.g. xcache. In this case, there is (at least) one kind of strict warnings cannot be caught by the error-handler, namely "Strict Standards: Assigning the return value of new by reference is deprecated" caused by code like this: $foo =& new Bar(). Apart from this, everything else works fine. Luckily there are only a few occurrences of this pattern in the PEAR packages that we use. A number of these are in the DB package. While there may be a marginal difference in performance, I believe these two statements are (almost) functionally identical: $foo =& new Bar(); $foo = new Bar(); The only exception I can think of is when using the emulated destructor system, e.g. Bar::_Bar (as mentioned on http://pear.php.net/package/PEAR/docs/latest/PEAR/PEAR.html#class_details ). This isn't used by DB. Any chance the latter form could be used by DB (I can see 3 occurrences in DB.php and 2 in DB/common.php)? As far as I am concerned, it makes no difference to PHP4 users or PHP5 users running without strict error reporting. This change was done in the Mail and Net_SMTP packages a while back, appearently without any problems - se bug 9947. This small change will ease PHP5+E_STRICT adoption (a Good Thing (TM) nowadays :-) without forcing users to upgrade from DB to MDB2 or similar and without annoying PHP4 users. Thanks :-)

I forgot that to avoid another strict warning is to add to dummy parameters to DB_common::raiseError() so that it matches the definition of PEAR::raiseError(), i.e. like this: function &raiseError($code = DB_ERROR, $mode = null, $options = null, $userinfo = null, $nativecode = null, $dummy1 = null, $dummy2 = false)

I'll have to think about this one. = and =& aren't functionally identical, and my natural inclination is not to make a change on the "if it ain't broke" principle, even though I can't think off-hand how it would be a problem to make the change. I'll play around with this when I'm working on bug #11580 and get back to you.

> = and =& aren't functionally identical Note that I only suggest changing the cases, where =& is followed by "new", e.g. "$foo =& new Bar()". Cases like "$foo =& $bar" is not a problem. AFAICS this only causes problems when "&$this" is used inside the constructor like in PEAR::_construct() where this is used to emulate destructors.

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.

The suggested change to raiseError() (adding two dummy parameters) wasn't included in the version just released, so I am reopening this bug (I hope that is okay). I still get the following error: Strict Standards: Declaration of DB_common::raiseError() should be compatible with that of PEAR::raiseError() in /var/home/dr/www/pear/DB/common.php on line 0 The other errors are gone, though.

Sorry, I missed that one. I'll fix it up in 1.7.14, but I don't think it warrants an early release.

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.