Switching to PHP 5 (.1) here is not an option yet either.
(and nobody can guarantee this same bug doesn't exist in it).
Regarding the magnitude: It's pretty damn high, if you look at how
many bug reports we've got about reference issues and large (huge)
codebases. (where finding the short reproducing script is impossible)
--Jani
On Mon, 30 May 2005, Zeev Suraski wrote:
At 17:10 30/05/2005, Derick Rethans wrote:
Not fixing it is *not* an option. You fix something that's broken - you
don't leave it broken. That's called responsibility. And no, switching
to PHP 5 is not an option either.
Sorry Derick, but you saying that not fixing it and/or that switching to PHP 5
are not valid options doesn't mean that they're not valid options. I think
that with the rarity of this issue and even higher rarity of it actually
causing problems, taking this approach is extremely valid. Breaking binary
compatibility inside a 'PHP version family' on the other hand is not an
option, we've decided not to do this 3 or 4 years ago, and I don't see any
reason to break this decision at all.
I for one think that (a) providing info and workarounds, and (b) pointing
people to use PHP 5 is a completely acceptable solution to a problem of this
magnitude, when compared to the cost of fixing it. Let's see what others
think.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
