Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71116 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35369 invoked from network); 13 Jan 2014 23:12:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2014 23:12:24 -0000 Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:43921] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 94/D8-21529-7D274D25 for ; Mon, 13 Jan 2014 18:12:24 -0500 Received: by klapt.com (Postfix, from userid 1006) id 917E023D6081; Tue, 14 Jan 2014 00:12:20 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on klapt.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [192.168.178.7] (dslb-178-007-117-039.pools.arcor-ip.net [178.7.117.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by klapt.com (Postfix) with ESMTPSA id 2B6F623D6069; Tue, 14 Jan 2014 00:12:19 +0100 (CET) To: Andrea Faulds Cc: Yasuo Ohgaki , PHP Developers Mailing List In-Reply-To: <52D462BB.9060309@ajf.me> References: <52D462BB.9060309@ajf.me> Content-Type: text/plain; charset="UTF-8" Date: Tue, 14 Jan 2014 00:12:15 +0100 Message-ID: <1389654735.6953.52.camel@ghost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: ab@php.net (Anatol Belski) Hi Andrea, On Mon, 2014-01-13 at 22:03 +0000, Andrea Faulds wrote: > > On 13/01/14 21:57, Yasuo Ohgaki wrote: > > What's the reason not to introduce larger int for 32bit platforms? > > Too much performance impact? > > I've wondered this myself. It makes me also wonder if it's the case > using 64-bit on 32-bit platforms is a little too slow, couldn't you just > transparently store 32-bit and then switch to 64-bit if necessary? > thanks for the idea, but it might be much more complex as one thinks. If one has to switch between 32 vs 64 bit in zval, it screams for API breach. For example with functions accepting integers by reference. Anyway, just a speculation right now :) Regards Anatol