Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80529 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57279 invoked from network); 15 Jan 2015 11:13:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2015 11:13:16 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.200 imap1-2.ox.privateemail.com Received: from [192.64.116.200] ([192.64.116.200:40827] helo=imap1-2.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/D6-14306-BC0A7B45 for ; Thu, 15 Jan 2015 06:13:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id B4AC0B00087; Thu, 15 Jan 2015 06:13:12 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at imap1.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap1.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UfnzmXpKSFdh; Thu, 15 Jan 2015 06:13:12 -0500 (EST) Received: from [137.50.175.149] (oa-edu-175-149.wireless.abdn.ac.uk [137.50.175.149]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 1378FB00068; Thu, 15 Jan 2015 06:13:08 -0500 (EST) References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <68229C26-4EEC-49DC-BA05-D5AC9728D1E8@ajf.me> <93376D88-A704-4F89-AB90-82EEDAE82081@ajf.me> <1E8DD8EB-D82C-42F4-9A55-4387078EF74A@ajf.me> Mime-Version: 1.0 (1.0) In-Reply-To: <1E8DD8EB-D82C-42F4-9A55-4387078EF74A@ajf.me> Content-Type: multipart/alternative; boundary=Apple-Mail-4BCD4D41-FF26-4787-8291-C250CF412D18 Content-Transfer-Encoding: 7bit Message-ID: <07AF4400-7E79-4E43-A397-7B6B6FD0DD24@ajf.me> Cc: Pierre Joye , PHP Internals X-Mailer: iPhone Mail (12B440) Date: Thu, 15 Jan 2015 11:13:05 +0000 To: Dmitry Stogov Subject: Re: [PHP-DEV] [RFC] Big Integer Support From: ajf@ajf.me (Andrea Faulds) --Apple-Mail-4BCD4D41-FF26-4787-8291-C250CF412D18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 15 Jan 2015, at 11:01, Andrea Faulds wrote: >=20 > Hey Dmitry, >=20 >> On 15 Jan 2015, at 07:56, Dmitry Stogov wrote: >>=20 >> ext/session and ext/json are required by most apps. >> Actually I stopped attempts to build it when I saw compilation errors in e= xt/session. >>=20 >> Thanks. Dmitry. >=20 > Oh dear, does ext/session not build? :/ >=20 > So far I've only built the branch with --disable-all. >=20 > In the case of most extensions, the main source of compilation errors will= be changes to certain Zend Engine functions. In particular, is_numeric_stri= ng_ex needs to support bigints now and has an extra parameter. I don't think= I changed very many other functions. >=20 > Porting extensions should for the most part be relatively simple. Most ext= ensions are just sets of functions and use zpp. If they're using the 'l' spe= cifier (Z_PARAM_LONG) they'll continue to work. In most cases there is no ne= ed to update an 'l' parameter to support bigints. The length of a string can= 't exceed PHP's max integer size, for example. Of course, there are some fun= ctions where it would have a clear benefit to add bigint support. >=20 > The main problem with extensions is 'z' (Sorry, accidentally sent too early) The main problem with most extensions is the 'z' format specifier which acce= pts any value. If it accepts IS_LONG then it needs to accept IS_BIGINT too. I= n many cases you can just convert the bigint to a long and maybe reject it o= r wrap it if it won't fit, if the function doesn't need to support large int= egers: case IS_BIGINT: if (!zend_bigint_can_fit_long(Z_BIG_P(some_zval))) { zend_error(E_WARNING, "$some_zval too large"); RETURN_FALSE; } else { lval =3D zend_bigint_to_long(Z_BIG_P(some_zval)); } break; Something like that would work in most cases. There is also convert_to_long.= I probably should have focussed more on extension support, maybe I'll start t= ry to port some of them, there's not that much Zend stuff left to do really.= I would have ported ext/json, but there's now the jsond RFC. =20 Any help would be appreciated. I am panicking a bit as there's not that long= to go before PHP7 feature freeze, assuming Zeev's timetable is actually fol= lowed. Though I think this feature should be doable: as I said, there's not m= uch Zend stuff left to do, and most extensions should be quite simple to por= t. Thanks. -- Andrea Faulds http://ajf.me/= --Apple-Mail-4BCD4D41-FF26-4787-8291-C250CF412D18--