Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71046 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5873 invoked from network); 10 Jan 2014 19:40:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2014 19:40:01 -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:38876] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9A/90-02085-09C40D25 for ; Fri, 10 Jan 2014 14:40:01 -0500 Received: by klapt.com (Postfix, from userid 33) id 6F33B23D6080; Fri, 10 Jan 2014 20:39:57 +0100 (CET) Received: from 188.110.167.245 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Fri, 10 Jan 2014 20:39:57 +0100 Message-ID: In-Reply-To: <85dd74125f8e35b77a16fb0e2fbaf301.squirrel@webmail.klapt.com> References: <85dd74125f8e35b77a16fb0e2fbaf301.squirrel@webmail.klapt.com> Date: Fri, 10 Jan 2014 20:39:57 +0100 To: "Kalle Sommer Nielsen" Cc: "PHP Developers Mailing List" Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: ab@php.net ("Anatol Belski") On Fri, January 10, 2014 20:32, Anatol Belski wrote: > Hi Kalle, > > > On Fri, January 10, 2014 19:29, Kalle Sommer Nielsen wrote: > >> Hi Anatol >> >> >> >> 2014/1/10 Anatol Belski : >> >> >>> Hi, >>> >>> >>> >>> https://wiki.php.net/rfc/size_t_and_int64 >>> >>> >> >> I absolutely love the work, time and effort you have put in to this >> branch, I've been following it closely on the sideline. There is one >> thing I'm wondering about, maybe I skipped through some of the >> sections too fast in the RFC, but what about API BC? I know you propose >> it for PHP6, but are there gonna be any macros or other helpers for >> extension developers to ease the use of #ifdefs, I realize things like >> the parameter parsing one is gonna be tough, but just as a general >> thought, I think Derick was asking something like this not too >> long ago? >> > thanks for the good words :) > > The short answer is: yes. I gonna start with that probably right as next. > In plan is the tool for any possible automatic replacements and the > header(s) for backward compatibility. That will be a big ease for the first > step, though it can of course not replace the manual porting. Parameter > parsing is one of the cracky points, but more it will be about the > extension code adoption. Especially size_t usage, while being trivial, > might get one in a muddle. I personally needed 1-2 hours to habituate > size_t, so it works. > Ah, btw it is on the RFC, a couple of sentences under "Migration path for PECL extensions". Anatol