Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74989 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10344 invoked from network); 19 Jun 2014 12:04:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jun 2014 12:04:16 -0000 Authentication-Results: pb1.pair.com header.from=andre.romcke@ez.no; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=andre.romcke@ez.no; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ez.no designates 213.199.154.80 as permitted sender) X-PHP-List-Original-Sender: andre.romcke@ez.no X-Host-Fingerprint: 213.199.154.80 mail-db3lp0080.outbound.protection.outlook.com Received: from [213.199.154.80] ([213.199.154.80:45556] helo=emea01-db3-obe.outbound.protection.outlook.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/22-30767-CB1D2A35 for ; Thu, 19 Jun 2014 08:04:15 -0400 Received: from AM3PR07MB386.eurprd07.prod.outlook.com (10.242.111.12) by AM3PR07MB388.eurprd07.prod.outlook.com (10.242.111.22) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 19 Jun 2014 12:04:08 +0000 Received: from AM3PR07MB386.eurprd07.prod.outlook.com ([10.242.111.12]) by AM3PR07MB386.eurprd07.prod.outlook.com ([10.242.111.12]) with mapi id 15.00.0959.000; Thu, 19 Jun 2014 12:04:08 +0000 To: Stas Malyshev CC: Julien Pauli , Remi Collet , "PHP Internals" Thread-Topic: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13 Thread-Index: AQHPi7aSYOl0g9729USThFS5WQ6Qwg== Date: Thu, 19 Jun 2014 12:04:06 +0000 Message-ID: <54FA010D-4FD7-48C9-8268-C1EF8D0B742F@ez.no> References: <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com> <53A2A9BD.1070603@sugarcrm.com> In-Reply-To: <53A2A9BD.1070603@sugarcrm.com> Accept-Language: nb-NO, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.12.86.239] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(428001)(5423002)(38414003)(199002)(51704005)(189002)(24454002)(76176999)(31966008)(77982001)(76482001)(85306003)(92566001)(92726001)(54356999)(81342001)(82746002)(33656002)(15188155005)(74482001)(50986999)(74502001)(74662001)(15202345003)(64706001)(79102001)(85852003)(86362001)(4396001)(83322001)(16799955002)(2656002)(19580395003)(99396002)(93886003)(21056001)(46102001)(19580405001)(20776003)(83072002)(83716003)(66066001)(36756003)(80022001)(15975445006)(95666004)(87936001)(101416001)(105586002)(106116001)(81542001)(104396001);DIR:OUT;SFP:;SCL:1;SRVR:AM3PR07MB388;H:AM3PR07MB386.eurprd07.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (: ez.no does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=andre.romcke@ez.no; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ez.no Subject: Re: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13 From: andre.romcke@ez.no (=?Windows-1252?Q?Andr=E9_R=F8mcke?=) Travis is now running PHP 5.4.29, tests are failing all over the place righ= t now*. When these kind of things happen, just take down the release while you work= out the details please. (* most people in the wild don=92t always use latests PHPUnit as it has a t= endency to break stuff badly, just look to the now dead Zeta Components for= a example of bad PHPunit breaks) On 19 Jun 2014, at 11:13 , Stas Malyshev wrote: > Hi! >=20 >> For me, it's a safe solution, however, it breaks BC, I think it's a >> no-go for 5.4 and 5.5. >=20 > 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. >=20 >> - Revert the BC break in 5.5 and 5.4 >> - Keep the segfault, we've been living with it for ages >=20 > 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. >=20 >> - 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) >=20 > 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? > --=20 > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20