Reference handling change and PHP 4.4.0

You do understand the difference between 4.3.x and 4.4.x? :) (yes, this issue has been beaten to death already) --Jani On Wed, 14 Sep 2005, Colin Tucker wrote:

Colin Tucker wrote:

We have been looking to see if there is a way to fix the memory corruption issue in a way that has less of an impact on existing code. This doesn't change the fact that every error you get is actually an error in the code you are running. The broken code is effectively doing something similar to: function foo(&$arg) { $arg = 4; } foo(strlen("abc")); which makes very little sense. There are many variations of this, but in every instance it is something that should be fixed, and in some of the cases it actually leads to memory corruption. There are many examples of this sort of thing working just fine in PHP 4.3.x because people are passing things in by reference and never modifying the passed in value. They'll do something along the lines of: function foo(&$arg) { return $arg[0] + 1; } echo foo(array(1,2,3,4,5,6,7,8,9,10)); possibly because they believe that they are saving memory by not making a copy of the array with that reference. Of course that is quite misguided as no copy is done until the arg is modified so if you don't modify it, you are better off passing it by value. Right now the change in 4.4 and 5.x is to complain loudly when you pass a reference to something without any associated storage. In both of the above examples there is no permanent storage associated with either of the passed arguments, so trying to get a reference to this storage makes very little sense. The only feasible way we might be able to work around this is to make a copy of such bogus reference attempts and effectively just pretend they were passed by value. I think it is a bit of a hack, but at the same time the breakage of existing apps has been more widespread than I think anybody anticipated. I'd still want to throw a notice to let people know they are doing something odd though. -Rasmus

On Wed, 14 Sep 2005, Colin Tucker wrote:

It already broke heaps of code - and this problems *was* affecting application with hard to find crashes. So yes, it is worth it.

Uhm, they're only notices - they shouldn't show up at the website in production, now should they?

PHP 4 is not going to change the behavior anymore. Derick

Hi again from an "ordinary user"! This thread has some opponents sharpening their knives in the corners. Hey guys, cool down! It's only ones and zeroes! ;-) First of all let's find some agreements points: - I think most of you agree that it was a bigger problem fixing it with warning in PHP4 than it was in PHP5. - Not fixing it was out of question because it caused memory corruption. Some time ago there were default options in the php.ini that are considered very harmful nowadays (register_globals etc) but they are still there, just carefully defaulting to off. See the similarities? If some people just want to use it this way the put in an option: unstored_references = NOTICE|IMPLICIT_TEMP_STORE So people relying on using it the old way can just switch it to automagically assigning a temp variable inbetween (or is this standard procedure since 4.4? Then just allow to switch the log level for such events.). On a side note it would help people if there was a possibility to run all kinds of PHP versons as Apache module in parallel which nowadays has to be done by patching the sources. Some PHP coders don't like the CGI variant and prefer the module and just for the sake of using the module they resign to doing all stuff with a single PHP version. Being able to run a 4.3.10 module in parallel with a 4.4 module and choosing the one to use on a per-directory-basis via .htaccess could calm a lot of voices. AllOLLi ____________ Time is an illusion. Lunchtime doubtly so. [Douglas Adams]

Hello again, Wow, this thread generated more heat than I thought it would, I basically just wanted to know the reasoning behind making the change to PHP4, unfortunate I guess for all involved that it went downhill. I have learned much in the past few days, at any rate. As mentioned, my code actually broke following the switch to 4.4.0, in addition to logging hundreds of E_NOTICE errors. It's taken me some time to track down where it's going wrong, but I think I've found out the culprits involved. It's complicated, I'll try to explain it all. The problem was related to components of my web app framework (which is similar to Struts, and incidently, now being phased out for a MUCH more lightweight, PHP5-based framework), in particular, an array of attributes, view helper classes and the creation of DAOs (data access objects) at runtime via XML configuration, which would look like this: <daos> <dao name="dao.freight" class="FreightDAO" component="Generic/Commerce/DAO/FreightDAO.php" /> <dao name="dao.customer" class="CustomerDAO" component="Generic/Commerce/DAO/CustomerDAO.php" /> <dao name="dao.order.status" class="OrderStatusDAO" component="Generic/Commerce/DAO/OrderStatusDAO.php" /> </daos> This XML would be parsed and the relevant DAO instances would be created and recorded in attribute scope for the current application module instance. For each dao node, the following code would be called (where $daoClass and $daoComponent are extracted from the XML attributes): $dao =& $this->_createDAO($daoClass,$daoComponent); if ($dao) { $this->module->setAttributeByReference($name,$dao); } Notice it assigns by reference, however I discovered that the _createDAO() method was not *returning* by reference: function _createDAO($daoClass=null,$daoComponent=null) { // Obtain Database Object: $database =& $this->module->findDatabase(); if (is_null($database)) { trigger_error($this->error(ERROR_DB_COULD_NOT_OBTAIN)); } else { // Obtain Database Connection: $connection =& $database->getConnection(); if (is_null($connection)) { trigger_error($this->error(ERROR_DB_COULD_NOT_CONNECT)); } else { // Create DAO Instance: $cmp =& new ClassComponent($daoClass,$daoComponent); $dao =& $cmp->getInstance(); if ($dao) { $dao->setConnectionByReference($connection); return $dao; } } } return NULL; } What was happening under PHP 4.4.0 is when the newly created DAO was added to the module as an attribute (setAttributeByReference), a new attribute would be created, but ALL existing DAOs in the attribute scope would become the newly added DAO, for example: (create and set the dao.freight attribute): attributes (array) { [dao.freight] => FreightDAO Object } (create and set the dao.customer attribute): attributes (array) { [dao.freight] => CustomerDAO Object [dao.customer] => CustomerDAO Object } (create and set the dao.order.status attribute): attributes (array) { [dao.freight] => OrderStatusDAO Object [dao.customer] => OrderStatusDAO Object [dao.order.status] => OrderStatusDAO Object } Simply by adding the ampersand to the _createDAO() method, like so: function &_createDAO($daoClass=null,$daoComponent=null) { } ...rectified the problem (however did not make hundreds of E_NOTICE's disappear, of course ;)). The question is, why did this problem not occur before 4.4.0? Is this an example of the "memory corruption"? Regards, Colin.

Hi I was lost in this thread. Could someone post resume from this discussion? How can I deal with this in 4.3, 4.4, 5+? Thanks