Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71045 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4349 invoked from network); 10 Jan 2014 19:33:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2014 19:33:05 -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:38713] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C2/40-02085-CEA40D25 for ; Fri, 10 Jan 2014 14:33:04 -0500 Received: by klapt.com (Postfix, from userid 33) id 3794623D6080; Fri, 10 Jan 2014 20:32:58 +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:32:58 +0100 Message-ID: <85dd74125f8e35b77a16fb0e2fbaf301.squirrel@webmail.klapt.com> In-Reply-To: References: Date: Fri, 10 Jan 2014 20:32:58 +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") 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. Cheers anatol