Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71923 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31252 invoked from network); 1 Feb 2014 13:24:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Feb 2014 13:24:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; 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:41182] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 13/00-30967-295FCE25 for ; Sat, 01 Feb 2014 08:24:35 -0500 Received: (qmail 4164 invoked by uid 89); 1 Feb 2014 13:24:31 -0000 Received: by simscan 1.3.1 ppid: 4158, pid: 4161, t: 0.0662s 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; 1 Feb 2014 13:24:31 -0000 Message-ID: <52ECF62A.5060401@lsces.co.uk> Date: Sat, 01 Feb 2014 13:27:06 +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: <1391171792.2941.130.camel@guybrush> <52EB9A16.5060605@phpdoc.de> <1391172906.2941.140.camel@guybrush> <9810c708a9fcc543a263365b5d7c2a63@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length and integer From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > Also see Anatol latest post to internals, the sample extension shows > the difference between a 5.3/4/5 code and one supporting 5.3/4/5 and > with the int64 patch with the option #2 and #3. The changes are really > straightforward and far less intrusive than without these options. I see that the vote currently has swung from yes to no for including in 5.6 but actually there is no option to include it even in PHP6? The improvement is required, needs proper planning because of the impact on many third parties, and should be planned now on the basis of a new PHP6. That said, I still see no reply to my enquiry as to how this will affect user land usage between 32 and 64 bit builds. To this end, vote 3 would seem to directly impact how we format displays and is one of the areas that I am concerned that there will be a difference between the two builds? What I would like to see in the RFC is some proper documentation on the differences between the two so that we can plan on how this is handled when moving from PHP5 to PHP6 ( even if you call it PHP5.6 ;) ) ... The current disagreement is not about including it, but simply how it is included. I would prefer that you now leave PHP5 alone and simply get on with a parallel development of PHP6 ... which currently the vote would seem to support? People how need the 64bit improvements can run PHP6 early ... I ran PHP5 for 6 months before it was actually released simply to avoid having to worry about 4 back then. A little bit of fun as things changed, but it keeps the effects of missing extensions nicely ring fenced? -- 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