# Reference handling change and PHP 4.4.0

- Thread: https://externals.io/message/18848
- Original archive: https://news-web.php.net/php.internals/18848
- Started by Colin Tucker on 2005-09-13T22:48:34+00:00
- Messages: 55
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/18848.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #18848 — Colin Tucker — 2005-09-13T22:48:34+00:00

URL: https://externals.io/message/18848#18848

Hello all,

I know this issue has most likely been discussed to death here so I 
apologise in advance for starting a new thread about it.  I just need to 
get my head around the reasoning for introducing this change to PHP4 
(4.4 branch).  I can understand making the change to PHP5, but can 
someone bring me up to speed as to why it was done to PHP4?  As I'm sure 
you're aware, it breaks heaps and heaps of existing code out there.

We found this out the hard way yesterday when our server administrator 
upgraded our production server to PHP 4.4.0 (even though the Debian 
package description said it was a PHP 4.3.x release).  We ended up with 
hundreds of errors and many, many vhosts stopped working correctly due 
to "variable references should be returned by reference" problems, both 
in my code and in third-party code, such as PHPBB instances.

And now I read that this will not be "fixed" in future PHP4 releases due 
to breaking backwards compatibility?  I just don't understand... a 
change that breaks backwards compatibility in a large portion of the 
existing PHP4 code base will not be fixed because it breaks backwards 
compatibility?  It's doing my head in, please can someone explain?

This means that either we have to (potentially) change thousands of 
lines of code and upgrade many instances of third-party PHP-based sites 
just to use PHP 4.4.0 and above, or miss out on using this and future 
PHP4 releases and any security vulnerability fixes they may include. 
Why could the change not be made optional by using a php.ini directive?

Kind regards,

Colin.

---

## #18849 — Jani Taskinen — 2005-09-13T23:22:08+00:00

URL: https://externals.io/message/18848#18849 · In reply to: #18848

You do understand the difference between 4.3.x and 4.4.x? :)
     (yes, this issue has been beaten to death already)

     --Jani




>
> Hello all,
>
> I know this issue has most likely been discussed to death here so I apologise 
> in advance for starting a new thread about it.  I just need to get my head 
> around the reasoning for introducing this change to PHP4 (4.4 branch).  I can 
> understand making the change to PHP5, but can someone bring me up to speed as 
> to why it was done to PHP4?  As I'm sure you're aware, it breaks heaps and 
> heaps of existing code out there.
>
> We found this out the hard way yesterday when our server administrator 
> upgraded our production server to PHP 4.4.0 (even though the Debian package 
> description said it was a PHP 4.3.x release).  We ended up with hundreds of 
> errors and many, many vhosts stopped working correctly due to "variable 
> references should be returned by reference" problems, both in my code and in 
> third-party code, such as PHPBB instances.
>
> And now I read that this will not be "fixed" in future PHP4 releases due to 
> breaking backwards compatibility?  I just don't understand... a change that 
> breaks backwards compatibility in a large portion of the existing PHP4 code 
> base will not be fixed because it breaks backwards compatibility?  It's doing 
> my head in, please can someone explain?
>
> This means that either we have to (potentially) change thousands of lines of 
> code and upgrade many instances of third-party PHP-based sites just to use PHP 
> 4.4.0 and above, or miss out on using this and future PHP4 releases and any 
> security vulnerability fixes they may include. Why could the change not be 
> made optional by using a php.ini directive?
>
> Kind regards,
>
> Colin.

---

## #18850 — Colin Tucker — 2005-09-13T23:26:26+00:00

URL: https://externals.io/message/18848#18850 · In reply to: #18849

Hi Jani,

Yes, the increase in the middle digit.  ;)

Ok, so does this mean that the 4.3.x and 4.4.x branches will now be 
updated separately?  Say, if a serious vulnerability was detected in 
4.3.x an 4.4.x, and separate release would be issued for both?

Kind regards,

Colin.

Jani Taskinen wrote:
> 
>     You do understand the difference between 4.3.x and 4.4.x? :)
>     (yes, this issue has been beaten to death already)
> 
>     --Jani

---

## #18852 — Pierre Joye — 2005-09-14T00:23:42+00:00

URL: https://externals.io/message/18848#18852 · In reply to: #18850

> Hi Jani,
> 
> Yes, the increase in the middle digit.  ;)
> 
> Ok, so does this mean that the 4.3.x and 4.4.x branches will now be
> updated separately?  Say, if a serious vulnerability was detected in
> 4.3.x an 4.4.x, and separate release would be issued for both?

No, 4.3.x is a dead branche. But the problem is much more easier to
fix in 4.4.0. Do what you always do in production servers, do not
display errors/notices, especially as 4.4.0 raises only notices for
the reference problem.

Regards,

--Pierre

---

## #18853 — Rasmus Lerdorf — 2005-09-14T00:25:39+00:00

URL: https://externals.io/message/18848#18853 · In reply to: #18848

Colin Tucker wrote:
> I know this issue has most likely been discussed to death here so I
> apologise in advance for starting a new thread about it.  I just need to
> get my head around the reasoning for introducing this change to PHP4
> (4.4 branch).  I can understand making the change to PHP5, but can
> someone bring me up to speed as to why it was done to PHP4?  As I'm sure
> you're aware, it breaks heaps and heaps of existing code out there.
> 
> We found this out the hard way yesterday when our server administrator
> upgraded our production server to PHP 4.4.0 (even though the Debian
> package description said it was a PHP 4.3.x release).  We ended up with
> hundreds of errors and many, many vhosts stopped working correctly due
> to "variable references should be returned by reference" problems, both
> in my code and in third-party code, such as PHPBB instances.
> 
> And now I read that this will not be "fixed" in future PHP4 releases due
> to breaking backwards compatibility?  I just don't understand... a
> change that breaks backwards compatibility in a large portion of the
> existing PHP4 code base will not be fixed because it breaks backwards
> compatibility?  It's doing my head in, please can someone explain?
> 
> This means that either we have to (potentially) change thousands of
> lines of code and upgrade many instances of third-party PHP-based sites
> just to use PHP 4.4.0 and above, or miss out on using this and future
> PHP4 releases and any security vulnerability fixes they may include. Why
> could the change not be made optional by using a php.ini directive?

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

---

## #18854 — Pierre Joye — 2005-09-14T00:36:30+00:00

URL: https://externals.io/message/18848#18854 · In reply to: #18853

> but at the same time the breakage of existing apps has been
> more widespread than I think anybody anticipated.

Than "anybody" liked to anticipate could better said.

> I'd still want to throw a notice to let people know they are doing something odd though.

As I said hundred of times in the past weeks to everyone and his
mother, yes, notices could be a much better choice for a first release
(both branches) than fatal errors or warning :-)

Regards,

--Pierre

---

## #18855 — Colin Tucker — 2005-09-14T00:51:31+00:00

URL: https://externals.io/message/18848#18855 · In reply to: #18853

Hi Rasmus, thanks for replying, I appreciate your feedback.

Rasmus Lerdorf 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.

Yes, I know this now, but I guess at the time it seemed ok, because it 
wasn't an error then.  :)

> 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.

Well for one I'm glad that PHP5 handles all objects as references now 
because this was primarily the reason I used references in PHP4, i.e. to 
ensure that copies of objects were not being passed around.  Plus, I'm 
now in the process of converting my core code to PHP5 using it's 'proper 
OO' features.  However, as you mentioned, this still leaves a lot of 
broken PHP4 code under 4.4 and above.  I completely understand now why 
the change was made, I just guess a lot of us were doing funny things 
with references that we shouldn't have been.  I suppose it's a tricky 
situation for you guys as there was no solution that wouldn't cause at 
least some breakage.

Cheers,

Colin.

---

## #18858 — Leigh Makewell — 2005-09-14T01:56:43+00:00

URL: https://externals.io/message/18848#18858 · In reply to: #18852

Pierre Joye wrote:
> No, 4.3.x is a dead branche. But the problem is much more easier to
> fix in 4.4.0. Do what you always do in production servers, do not
> display errors/notices, especially as 4.4.0 raises only notices for
> the reference problem.
> 
> Regards,
> 
> --Pierre

Well that is exactly why this is a problem. Making large changes that 
break BC in php 5 is fine because there are two versions that are being 
maintained, php4, and php5. Security updates are made to both.

However, breaking BC between 4.3 and 4.4 when 4.3 is a dead branch 
causes can cause some problems for system admins. What happens if the 
software being used is never updated to 4.4? There are important 
security updates that need to be applied, but they can't apply them 
because all of their websites will stop working.

Oh and not displaying the error doesn't make the error go away :p

---

## #18859 — Rasmus Lerdorf — 2005-09-14T02:36:20+00:00

URL: https://externals.io/message/18848#18859 · In reply to: #18858

Leigh Makewell wrote:
> Pierre Joye wrote:
> 
> > […]
> 
> 
> Well that is exactly why this is a problem. Making large changes that
> break BC in php 5 is fine because there are two versions that are being
> maintained, php4, and php5. Security updates are made to both.
> 
> However, breaking BC between 4.3 and 4.4 when 4.3 is a dead branch
> causes can cause some problems for system admins. What happens if the
> software being used is never updated to 4.4? There are important
> security updates that need to be applied, but they can't apply them
> because all of their websites will stop working.
> 
> Oh and not displaying the error doesn't make the error go away :p

Once again, it is an `E_NOTICE` in 4.4.  And yes, not displaying it makes
it go away.  Staying with 4.3 because of this is nuts.  If you are
seeing this notice under 4.4 that means you are most likely getting
random memory corruption under 4.3.  Move to 4.4 to fix the memory
corruption.  Go through the notices and fix as many of them as you can,
since it indicates a basic problem in the code you are running.  If you
are not interested in doing that, just turn them off.  It will run
without corruption.

-Rasmus

---

## #18860 — Colin Tucker — 2005-09-14T02:57:56+00:00

URL: https://externals.io/message/18848#18860 · In reply to: #18859

Rasmus Lerdorf wrote:
> Once again, it is an `E_NOTICE` in 4.4.  And yes, not displaying it makes
> it go away.  Staying with 4.3 because of this is nuts.  If you are
> seeing this notice under 4.4 that means you are most likely getting
> random memory corruption under 4.3.  Move to 4.4 to fix the memory
> corruption.  Go through the notices and fix as many of them as you can,
> since it indicates a basic problem in the code you are running.  If you
> are not interested in doing that, just turn them off.  It will run
> without corruption.
> 
> -Rasmus

Hi again Rasmus,

Well, I can tell you that following our unexpected server upgrade 
yesterday to 4.4.0, things definately DID break within our code, and the 
display of `E_NOTICE` errors is disabled on our production server.  We 
quickly rolled back to 4.3, and I have not had a chance to fully 
investigate what is going on with the code as yet, but it seemed to be 
stemming from a class of mine that acts like a map.  Instead of 
returning an object associated with a given key, it was returning the 
*last added* object.  I think all objects in the map ended up being the 
same object, being the last one added - there is definately some 
reference weirdness going on.  I'm as confused as you probably are, and 
will report back on what is going wrong when I have a chance.  But one 
thing is sure, this code was working absolutely fine until the switch to 
4.4.0.

Cheers,

Colin.

---

## #18878 — Derick Rethans — 2005-09-14T12:40:52+00:00

URL: https://externals.io/message/18848#18878 · In reply to: #18848

> Hello all,
> 
> I know this issue has most likely been discussed to death here so I apologise
> in advance for starting a new thread about it.  I just need to get my head
> around the reasoning for introducing this change to PHP4 (4.4 branch).  I can
> understand making the change to PHP5, but can someone bring me up to speed as
> to why it was done to PHP4?  As I'm sure you're aware, it breaks heaps and
> heaps of existing code out there.

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

> We found this out the hard way yesterday when our server administrator
> upgraded our production server to PHP 4.4.0 (even though the Debian package
> description said it was a PHP 4.3.x release).  We ended up with hundreds of
> errors and many, many vhosts stopped working correctly due to "variable
> references should be returned by reference" problems, both in my code and in
> third-party code, such as PHPBB instances.

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

> And now I read that this will not be "fixed" in future PHP4 releases due to
> breaking backwards compatibility?  I just don't understand... a change that
> breaks backwards compatibility in a large portion of the existing PHP4 code
> base will not be fixed because it breaks backwards compatibility?  It's doing
> my head in, please can someone explain?

PHP 4 is not going to change the behavior anymore.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #18880 — Derick Rethans — 2005-09-14T12:42:03+00:00

URL: https://externals.io/message/18848#18880 · In reply to: #18858

> However, breaking BC between 4.3 and 4.4 when 4.3 is a dead branch causes can
> cause some problems for system admins. What happens if the software being used
> is never updated to 4.4? There are important security updates that need to be
> applied, but they can't apply them because all of their websites will stop
> working.

I doubt any application would really stopped working - except for a 
friendly notice when people wrote bad code.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #18932 — Pierre Joye — 2005-09-14T12:46:21+00:00

URL: https://externals.io/message/18848#18932 · In reply to: #18880

> I doubt any application would really stopped working - except for a
> friendly notice when people wrote bad code.

Derick, I do not know if you ever learn but... Stop saying that people
wrote bad codes and this is why they code could break. This is nothing
else than _wrong_ and respectless.

Regards,

--Pierre

---

## #18891 — Leigh Makewell — 2005-09-14T13:42:40+00:00

URL: https://externals.io/message/18848#18891 · In reply to: #18880

Derick Rethans wrote:
> I doubt any application would really stopped working - except for a 
> friendly notice when people wrote bad code.
> 
> Derick
> 

Except if you had read Colin's messages you would see that his code 
*had* stopped working.

Leigh :)

---

## #18892 — Derick Rethans — 2005-09-14T13:48:27+00:00

URL: https://externals.io/message/18848#18892 · In reply to: #18891

> Derick Rethans wrote:
> > […]
> 
> Except if you had read Colin's messages you would see that his code *had*
> stopped working.

But it just could as well have been because he was relying on the memory 
corruptions. Hard to tell without code.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #18938 — Colin Tucker — 2005-09-14T22:26:59+00:00

URL: https://externals.io/message/18848#18938 · In reply to: #18878

Derick Rethans wrote:
> > […]
> 
> Uhm, they're only notices - they shouldn't show up at the website in 
> production, now should they?

Derick, can you show me where I said that they showed up on the website?

> > […]
> 
> PHP 4 is not going to change the behavior anymore.

Sorry, but that doesn't really answer my question.

Regards,

Colin.

---

## #18939 — Colin Tucker — 2005-09-14T22:37:22+00:00

URL: https://externals.io/message/18848#18939 · In reply to: #18892

Derick Rethans wrote:
> But it just could as well have been because he was relying on the memory 
> corruptions. Hard to tell without code.
> 
> Derick

As I mentioned in my reply to Rasmus above, the problem seems to be 
stemming from a class that acts like a map of objects.  Most of my PHP4 
code would pass objects around by reference to ensure operations were 
working on the original object, thus avoiding the creation of copies. 
After the upgrade to 4.4.0, the map lost integrity in that returning any 
object within the map by key would return the object last added to the 
map.  I may not have provided any code, but this problem description was 
enough for Todd Ruth to send me a very helpful and informative e-mail on 
the matter (i.e. "everything the same as the last added" bugs), which 
shall help me greatly in tracking it down (thanks again, Todd!).

Regards,

Colin.

---

## #18942 — Todd Ruth — 2005-09-15T02:29:31+00:00

URL: https://externals.io/message/18848#18942 · In reply to: #18939

For the record, I have no idea how the 4.3 -> 4.4 change could trigger
such a bug.  I just pointed out that we've hit the symptom Colin
described many times in our company with code (yes, bad code) of 
the form:

<?php
function &f(&$y) { return $y; }
$x = array('a','b','c');
foreach ($x as $y) {
   // The following line is a bad use of "&".  It doesn't
   // do any good and ends up causing all the members of $z
   // to be references to eachother.
   $z[] =& f($y);
}
var_dump($x);
var_dump($z);
?>

I've played with many flavors of this user-bug, adding and
subtracting "&"s, but have been unable to get different 
behavior between 4.3 and 4.4.  Colin, when you find the code
that went wild in the switch to 4.4, please post it.  I'm
sure there are others that are as curious as I am.  (There
may even be someone nice enough to fix the BC break if
it doesn't mean reintroducing memory corruptions.)

As long as I'm posting, I might as well put in a "thank you"
note for the notices.  I know they're generating a lot of
heat, but it's made it soooo much easier to fix all of the
novice uses of "&"s in our code.

Thanks,
Todd

> ...  I may not have provided any code, but this problem description was 
> enough for Todd Ruth to send me a very helpful and informative e-mail on 
> the matter (i.e. "everything the same as the last added" bugs), which 
> shall help me greatly in tracking it down (thanks again, Todd!).
> 
> Regards,
> 
> Colin.

---

## #18945 — Leigh Makewell — 2005-09-15T03:12:53+00:00

URL: https://externals.io/message/18848#18945 · In reply to: #18892

Derick Rethans wrote:
> 
> 
> 
> > […]
> 
> 
> But it just could as well have been because he was relying on the memory 
> corruptions. Hard to tell without code.

I would like to start by apologising for this message. It's long, it's a 
rant, and I know this is probably not the place, but I can't let this 
slide. This sort of comment really annoys me.

Zip it up Derick! Who do you think you are to dictate whether Colin's 
code is good or bad?

You are very quickly starting to annoy a lot of PHP programmers. A quick 
search on this topic will find quite a few news posts, and forum threads 
discussing this issue, and I have seen you posting on a lot of them. You 
seem to have a "So What" attitude and are very quick to tell all these 
people that they are writing bad code and it's not your problem. We 
don't appreciate being told that we write bad code. We don't appreciate 
being treated as second rate programmers. We don't like being told that 
a perfectly legal statement like this $x = current(explode(' ','a b')); 
is wrong and bad programming!

Who are we? We are the top 10% of PHP programmers. We are the PHP coders 
who take your language and manipulate it, coerce it, and gently push it 
into doing things you never imagined it for. We are the few people who 
actually use 100% of PHP's abilities. We are the ones who will notice 
*every* time you make a change like this. Do you want PHP to be taken 
seriously and used professionaly? Well *we* are the ones who decide that 
PHP is ready for the big time, and if we believe that the floor is 
constantly shifting under us and making our job harder then we will 
leave. If we leave PHP will be nothing but a toy box language suitable 
for nothing but basic little guestbook scripts coded by school children.

I have enjoyed using PHP since the first script I wrote with it. But I 
am quickly losing that enjoyment, and not because of anything that has 
happened to the language. I am losing it because I feel like the PHP 
community does not respect it's users. As someone who works for a 
company that specialises in creating, building, and maintaining online 
communities I know how important good PR is. Like it or not PHP *is* an 
online community and it can be made or broken by it's people. Letting 
people like Derick here mouth off is not a good way to keep your 
community happy.


Leigh.

---

## #18946 — Rasmus Lerdorf — 2005-09-15T03:51:29+00:00

URL: https://externals.io/message/18848#18946 · In reply to: #18945

Leigh Makewell wrote:
> a perfectly legal statement like this $x = current(explode(' ','a b'));

In this particular case, `current()` did not need to take a reference
since it doesn't modify anything.  This has been fixed in CVS.  That's
still not how I'd write that though.  I would write:

  list($x) = explode(' ','a b');

Another way to write this:

  $x = array_shift(explode(' ','a b'));

This is where it gets tricky.  Is this legal code?  We are modifying the
argument and immediately discarding the modification.  The user might
want to know about that, so to me it makes sense that this throws a
NOTICE.  I do agree with folks who don't like this being a fatal error.
 I don't think it should be either and this is what we have been
discussing.  That doesn't change the fact that a lot of these examples
are not optimal coding examples.  There are usually more direct ways
that doesn't involve a useless operation that ends up getting discarded
right away.  So while the tone of some of these messages may not be
great, often the suggestion that the code in question isn't very good is
 accurate.

-Rasmus

---

## #18947 — Leigh Makewell — 2005-09-15T04:28:06+00:00

URL: https://externals.io/message/18848#18947 · In reply to: #18946

Rasmus Lerdorf wrote:
> This is where it gets tricky.  Is this legal code?

Yes it is legal because it worked. Whether it is strictly "correct" or 
not is another argument. People write bad code all the time, but it 
doesn't make it any less legal. In minor version changes BC is not a 
secondary priority. It *must* be the first, even if that means allowing 
things that are not strictly correct. If this isn't done then PHP will 
never be taken seriously.

However, this is completely not the point. My rant was more about 
attitude than anything else.

You yourself just admitted that this has been fixed in CVS. If that is 
so, then why was the relevant bug marked Bogus? 
http://bugs.php.net/bug.php?id=34468 with a wonderfully insightful 
comment courtesy of Derick "Feel free to fix the whole engine though 
with a patch...". I don't know if you realise this or not, but PHP is 
very quickly becoming a joke. People critisise and joke about PHP's 
automatic "Bogus" bot that just trolls through the database and marks 
any submitted bugs as "Bogus". What is the point of making the bug 
database public?

Read Marcus's comment on here in response to the ever eloquent Derick again:
"I will no longer report bugs to php.net and you can leave all your 
breakages in (actually they are always marked as bogus even when they 
result in repeatable server crashes, so I'd given up anyway)."
http://phplens.com/phpeverywhere/?q=node/view/214

That is just one example. PHP is famous for it's arrogance, and this 
just highlights it. Why should we bother to continue to support the 
community when the community doesn't support us? We owe PHP nothing. 
There are plenty of alternatives out there.

Now don't get me wrong. This is not aimed at everyone. I believe you 
Rasmus has tried to be diplomatic about everything, but understand that 
in these situations people don't look at individuals, so when a few 
individuals act badly people will project that onto the entity as a whole.

Leigh.

---

## #18948 — Colin Tucker — 2005-09-15T04:29:24+00:00

URL: https://externals.io/message/18848#18948 · In reply to: #18946

Rasmus Lerdorf wrote:
> So while the tone of some of these messages may not be great,
 > often the suggestion that the code in question isn't very good is
> accurate.

Rasmus, I think where some of the concern and confusion lies is with 
those of us who have been doing, or at least attempting, some "heavy" 
OOP with PHP4.  Now, PHP4 may not be the most ideal platform for OOP 
(hence the changes PHP5 brings), but nevertheless it *is* there, it is 
available to use, and despite it's shortcomings, use it we did.

Many of us who did some crazy OOP in PHP4 have used references heavily 
because, like in PHP5, we wanted to avoid making copies of objects 
everywhere.  Hence, a lot of code returns by reference and assigns by 
reference.  At the time, I certainly didn't think I was writing "bad" 
code - it seemed to make sense, and PHP4 happily ran it as expected 
without error or complaint.  Code like this, for example:

function &getProcessor()
{
    return $this->processor->getInstance();
}

...where the processor attribute is a dynamically-configured object 
which may generate a different object instance (from getInstance() call) 
depending on it's configuration.  Now in 4.4, this of course generates a 
notice, and has to be changed to:

function &getProcessor()
{
    $instance =& $this->processor->getInstance();

    return $instance;
}

...which to me just seems like a waste of space.  This raises other 
questions, for example, what if we're trying to return something by 
reference and encounter a problem with returning that something?  For 
example, take some sort of collection or list class:

function &at($index=NULL)
{
    if ($this->hasIndex($index))
    {
       return $this->elements[$index];
    }

    return NULL;
}

...you want to grab an element at the specified index by reference if 
it's an object.  The above code used to work fine, but now of course it 
generates a notice, and needs to be changed to something like:

function &at($index=NULL)
{
    $element = NULL;

    if ($this->hasIndex($index))
    {
       $element =& $this->elements[$index];
    }

    return $element;
}

These things by themselves are not a big deal, but many of us have these 
"little" issues happening throughout our code, resulting in hundreds 
upon hundreds of notices per page request.  Perhaps according to the 
true nature of references these examples were not the ideal way to code, 
but I don't consider it "bad code", and it was certainly legal and 
fully-functional code for some time now.  Call it awful if you like, but 
it certainly made sense to me at the time.

Regards,

Colin.

---

## #18949 — Rasmus Lerdorf — 2005-09-15T04:34:36+00:00

URL: https://externals.io/message/18848#18949 · In reply to: #18947

Leigh Makewell wrote:
> Rasmus Lerdorf wrote:
> 
> > […]
> 
> Yes it is legal because it worked. 

Well, that is the point, it didn't actually work.  Code similar to this
caused memory corruption.  So while you may not have seen an instant
crash, over time and in certain conditions you would get unexplained
crashes.  In order to fix this bug we needed to check for this sort of
code and in doing so we were able to fix it and also enhance the warning
levels to let people detect this sort of potentially bogus code.

-Rasmus

---

## #18951 — Leigh Makewell — 2005-09-15T07:23:31+00:00

URL: https://externals.io/message/18848#18951 · In reply to: #18949

Rasmus Lerdorf wrote:
> Well, that is the point, it didn't actually work.  Code similar to this
> caused memory corruption.  So while you may not have seen an instant
> crash, over time and in certain conditions you would get unexplained
> crashes.  In order to fix this bug we needed to check for this sort of
> code and in doing so we were able to fix it and also enhance the warning
> levels to let people detect this sort of potentially bogus code.
> 
> -Rasmus

You don't seem to understand. I'll let you in on a secret. We don't care 
about the php engine and how it works. What we care about is the PHP 
code and whether that works. Like it or not you set a precedent. You 
allowed us to write code that worked. Maybe it didn't work 100% and 
occasionally caused a crash, but that doesn't change the fact it worked. 
It must of worked otherwise people wouldn't of written it that way.

The fact that there was some memory corruption occuring occasionally is 
a bug in *your* system. We don't care why it happens, or what is causing 
it. All we do care about is that it gets fixed.

You have now demonstrated to us that the PHP developers can't be 
bothered trying to find a real solution so you decided to pass the buck 
and make us, your users, fix it for you. That is why we are angry. How 
do we know this won't happen again? What happens next time you find a 
bug that is just too hard? Will we have to change our code on every 
version release? How much is that going to cost us in time and money, 
and why should we bother?

---

## #18955 — Rasmus Lerdorf — 2005-09-15T11:03:39+00:00

URL: https://externals.io/message/18848#18955 · In reply to: #18951

Leigh Makewell wrote:
> Rasmus Lerdorf wrote:
> 
> > […]
> 
> You don't seem to understand. I'll let you in on a secret. We don't care
> about the php engine and how it works. What we care about is the PHP
> code and whether that works. Like it or not you set a precedent. You
> allowed us to write code that worked. Maybe it didn't work 100% and
> occasionally caused a crash, but that doesn't change the fact it worked.
> It must of worked otherwise people wouldn't of written it that way.

That's fine, and you shouldn't care, I agree.  I argued much the same
point just yesterday in a chat with Ilia.  You do however seem to be
glossing over the fact that this new check can be very helpful.  Take
this case:

  sort(array(3,2,1));

Or any other example where the function in question has no other purpose
than to modify its argument.  When you pass in something to a function
like this which has no permanent storage, chances are pretty high that
this is a bug in the code and you probably want to know about that.  So
I really don't see this as such a black and white case.  I am all for
making this a non-fatal error in all cases to allow scripts to keep
working, but I don't buy the argument that just because we didn't check
for this before we are not allowed to check for it now when it can find
valid bugs like this.

-Rasmus

---

Next page: https://externals.io/message/18848.md?page=2