Leigh Makewell wrote: > 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.
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
