Re: An BC issue in unserialize

On Thu, Jul 17, 2014 at 8:43 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > > > IMHO this isn't something we should change in a 2nd digit release, but > on a > > major version, even if it wasn't documented. > > We don't have much option here. Keeping it leads to a remote triggerable > segfaults. We've discussed this here just recently. This is a hack that > does not work properly with internal classes, and should not work too - > the whole reason C: was created is because O: can not work with such > classes. > As discussed in previous threads about this failure, we (doctrine) can move away from the unserialize() hack if ReflectionClass#newInstanceWithoutConstructor() provides support for internal classes. It doesn't need to cover ALL internal classes, just the most commonly extended ones. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/