Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74314 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90883 invoked from network); 17 May 2014 21:09:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 May 2014 21:09:44 -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.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:47890] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7E/08-53190-710D7735 for ; Sat, 17 May 2014 17:09:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3351C5043C; Sat, 17 May 2014 17:09:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D78955041B; Sat, 17 May 2014 17:09:40 -0400 (EDT) Message-ID: <5377D014.3020705@sugarcrm.com> Date: Sat, 17 May 2014 14:09:40 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nikita Popov , PHP internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Before going any further, it should be established that two aspects of the > 64 bit patch are, as far as I can see, acceptable to everyone: The > introduction of 64bit integers on Win64 and other LLP64 architectures and > the use of an unsigned integer type for lengths and sizes. I would add a third aspect - using a dedicated set of types to signify those, instead of relying on (potentially unportable) mishmash of standard ones. This is being overlooked, but I'd like to emphasize that I actually like the idea very much - with all the disruption that it brings - as a chance to weed out all these false assumptions and sloppy types still lurking in the guts of the engine and the extensions. I wonder if we can also make clang to tell us on such type conversions even if they match on specific system (I know there are hacks to do this but they are way uglier than I'd like to use). As for the rest, I think this is an excellent proposal and I agree with pretty much all of it. I am still not convinced of the need for 64-bit string sizes, but if we will be able to deal with much more important issues - such as hashtables, internal name lengths (function/class), etc. - I don't care, the difference is too small. I am not sure how the technical details with zend_string will work out but if we agree that's what we're doing and try to find the way to make it happen I'd think it worth a serious try. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227