Re: Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13

Hi! > For me, it's a safe solution, however, it breaks BC, I think it's a > no-go for 5.4 and 5.5. It breaks BC in something that never was part of the official API, never was promised to work and works only by accident for internal classes. Each such object can segfault at smallest provocation, so keeping them is essentially requiring that we keep segfault compatibility. I don't think we should promise that. > - Revert the BC break in 5.5 and 5.4 > - Keep the segfault, we've been living with it for ages That's not the reason not to fix segfaults. Virtually every bug we're fixing in the code we have been "living with for ages". That's not the reason to keep them now that we know it segfaults. > - Patch the manual to clearly show one should never try to unserialize > hand-made strings : we just do not support such behavior (thus, it > could lead to segfaults) Well, here we contradict ourselves then - if we do not support such behavior, why we are taking so much effort to enable it? Because declaring that changing something even in small part is inacceptable even if the price is known crashes in the application (and I wonder what security people can make of it - uninitialized objects might be way worse than just null pointer deref...) - that looks a lot like supporting to me. So in what meaning we don't support it then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227