Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74986
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <53A2A9BD.1070603@sugarcrm.com>
Date: Thu, 19 Jun 2014 02:13:33 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julien Pauli <jpauli@php.net>
CC: Remi Collet <remi@fedoraproject.org>, 
 PHP Internals <internals@lists.php.net>
References: <CAH-PCH6xEXspisLOHtiTbViA4vDTk7q6LM3t_Bh9Dzr1cj_Nag@mail.gmail.com> <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com> <CAMUwpuT_S2EE6cdJM95RzY4vmORGx3vJ9+gau8G3EZCMsNSydA@mail.gmail.com>
In-Reply-To: <CAMUwpuT_S2EE6cdJM95RzY4vmORGx3vJ9+gau8G3EZCMsNSydA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Problems with the fix for the BC break introduced
 in 5.4.29 and 5.5.13
From: smalyshev@sugarcrm.com (Stas Malyshev)

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