Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71941 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71970 invoked from network); 1 Feb 2014 20:58:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Feb 2014 20:58:10 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:47738] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/E6-30967-0EF5DE25 for ; Sat, 01 Feb 2014 15:58:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6771C1B0092; Sat, 1 Feb 2014 15:58:06 -0500 (EST) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id AE1941B0091; Sat, 1 Feb 2014 15:58:05 -0500 (EST) Message-ID: <52ED5FDD.8030101@sugarcrm.com> Date: Sat, 01 Feb 2014 12:58:05 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pierre Joye CC: Derick Rethans , Anatol Belski , PHP Developers Mailing List , Matt Ficken , "Stephen A. Zarkos" References: <52EAF181.3000907@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length and integer From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > There is a massive misunderstanding about the options provided in the votes. > > If the option #2 and #3 are accepted, only, I repeat, only the > declarations of the variables used by zpp have to be changed, nothing > else, no #ifdef, etc. I understand this. What is worrying me is that if you fail to do that for some function, you end up using wrong variable type, and it would lead to bugs that, from experience, are *very* hard to catch. If you break the code explicitly, it plants a huge red flag saying "Here! You need to fix this!". But if you just silently accept wrong types (and zpp has no way of doing typechecks) then your best red flag would come in the form of a user complaining "my PHP server crashes under the high load with PHP 5.6". I.e. if you do zpp("s", &char_ptr, &len) and zpp now expects len to be size_t but you keep it declared as int, no tool will alert you and you're putting 64-bit value into 32-bit stack slot. > It can be automated for zpp, it is almost the case already and Anatol > is working on this part to fully automate zpp changes (with option #2 > and #3). The bad part is not zpp. zpp is the easy part. The bad part is all vars outside zpp and keeping them all in sync. > I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the > int64 branch, it will be a better example than what we can see in > mongodb, which does not use option #2 and #3. It is basically bad as > many of us only focus on this constellation and totally ignore these > options which were added as a possible very good compromise. I'm not ignoring that option. On the contrary, it is exactly that option that you describe that I am worried about. And I am worried about it exactly because since you don't have (meaning, forced by the compiler or by zpp failure) to make the changes in all functions, it's all too easy to miss one, and missing one is all to hard to figure out. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227