Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71428 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18239 invoked from network); 23 Jan 2014 10:54:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2014 10:54:21 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:58942] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/B1-08036-BD4F0E25 for ; Thu, 23 Jan 2014 05:54:20 -0500 Received: (qmail 26820 invoked by uid 89); 23 Jan 2014 10:54:16 -0000 Received: by simscan 1.3.1 ppid: 26804, pid: 26817, t: 0.0731s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 23 Jan 2014 10:54:16 -0000 Message-ID: <52E0F55F.4040802@lsces.co.uk> Date: Thu, 23 Jan 2014 10:56:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > I think we can clear these questions during the vote phases, as options. > > If anyone has an idea how to keep the advantage brought by the > renaming (compile checks, clarity, code correctness) without actually > doing the renaming in extensions, please fire it:) Is this still being put forward for a PHP5.x build? Surely this along with a tidy up on base modules that support it would be much better used as a base for a new PHP6 plan? Extensions that do not support it can also be left out and we have a clean demarcation. One thing I would ask is just what 32bit platforms will remain supported. While desktop machines are generally 64bit these days, tablet and mobile devices do still tend to be 32bit. The ITX based systems I'm working with are still 32bit and while they do tend to run as clients to bigger servers, some support their own PHP platform. I already have to support different integer sizes anyway and assuming PHP is 32bit simplifies things but I'm a little unsure how a change to direct support for 64bit might affect that split? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk