Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87909 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44658 invoked from network); 25 Aug 2015 13:25:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2015 13:25:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:48052] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/D3-05482-3BC6CD55 for ; Tue, 25 Aug 2015 09:25:08 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id D773923D615C; Tue, 25 Aug 2015 15:25:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from w530phpdev (pD9FE840E.dip0.t-ipconnect.de [217.254.132.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 4E90023D6003; Tue, 25 Aug 2015 15:25:01 +0200 (CEST) To: "'Jakub Zelenka'" Cc: "'Dmitry Stogov'" , "'Rowan Collins'" , "'PHP Internals'" References: <02a601d0dbed$2c828df0$8587a9d0$@belski.net> <02ae01d0dbf5$01c17330$05445990$@belski.net> <02b001d0dbf5$607ab7b0$21702710$@belski.net> <02ba01d0dbfb$3de2c390$b9a84ab0$@belski.net> <55DA4924.2060401@gmail.com> <00c101d0de77$4a809680$df81c380$@belski.net> <01bd01d0df2a$f2484f30$d6d8ed90$@belski.net> In-Reply-To: Date: Tue, 25 Aug 2015 15:25:00 +0200 Message-ID: <01e301d0df39$7349a300$59dce900$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK9NdJN9egRUY1Umglkf8yuRLR3fgF0Y2w7Afrl8XkB4m4i6wDvLFLZAq3KEX4CFSYQhQFhBjf9Ai+bDhcB4PvUaQH8FipzAZG9Rt+bo+g9MA== Content-Language: en-us Subject: RE: [PHP-DEV] Overflow checks and integral vars comparison From: anatol.php@belski.net ("Anatol Belski") Hi Jakub, > -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of = Jakub > Zelenka > Sent: Tuesday, August 25, 2015 2:46 PM > To: Anatol Belski > Cc: Dmitry Stogov ; Rowan Collins > ; PHP Internals > Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison >=20 > Hi Anatol, >=20 > On Tue, Aug 25, 2015 at 12:41 PM, Anatol Belski = > wrote: >=20 > > Hi Dmitry, > > > > > -----Original Message----- > > > From: Dmitry Stogov [mailto:dmitry@zend.com] > > > Sent: Tuesday, August 25, 2015 9:29 AM > > > To: Anatol Belski > > > Cc: Rowan Collins ; PHP Internals > > > > > > Subject: Re: [PHP-DEV] Overflow checks and integral vars = comparison > > > > > > Hi Anatol, > > > > > > I don't see any problem adding ZEND_LONG_INT_OVF and similar = macros > > > into 7.0. > > > > > Thanks for taking a look. I was doing a quick RFC draft yesterday = also > > including a ZPP suggestion from Jakub. But given there's some demand > > on such checks still, probably better I withdraw the RFC and work > > towards macros for the range checks and integrating them at the = appropriate > places. > > Pure internal stuff anyway. > > > > > I think it makes sense to merge all macros without RFC to master for = 7.0 and > keep RFC just for ZPP changes as there might be some discussion about = the > names (e.g. "r" is already used for resources ;) ). Or maybe just = check if everyone > is ok with names (ZPP flags) and then integrate it as well. In any = case, it would be > nice to have this in ZPP at some point. >=20 Yep, was just a quick writing yesterday, overseen the 'r'. Actually pity = as it could be like 'q', 'r,', 's' ... easy to memorize :) With ZPP there could be also a little performance concern, as it would = add four cases to parse to ZPP yet. So probably also depends on which = scale it is needed. And another point is that an implementation with the = fast ZPP were needed as well. So turns out as a bit more than it looked = at the start, but would be IMHO useful from the functional sight. I'd be working of the macros next days, to cover as much as possible = then. Regards Anatol