Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84105 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22793 invoked from network); 1 Mar 2015 14:02:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Mar 2015 14:02:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=tpunt@hotmail.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tpunt@hotmail.co.uk; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.co.uk designates 157.55.1.151 as permitted sender) X-PHP-List-Original-Sender: tpunt@hotmail.co.uk X-Host-Fingerprint: 157.55.1.151 dub004-omc2s12.hotmail.com Received: from [157.55.1.151] ([157.55.1.151:62408] helo=DUB004-OMC2S12.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5B/F7-63732-30C13F45 for ; Sun, 01 Mar 2015 09:02:44 -0500 Received: from DUB113-W139 ([157.55.1.136]) by DUB004-OMC2S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 1 Mar 2015 06:02:40 -0800 X-TMN: [BYTqJhlKRgXIZXIol+mhnLblZcAvc1av] X-Originating-Email: [tpunt@hotmail.co.uk] Message-ID: To: Zeev Suraski , PHP internals Date: Sun, 1 Mar 2015 14:02:40 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2015 14:02:40.0542 (UTC) FILETIME=[618733E0:01D05428] Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC From: tpunt@hotmail.co.uk (Thomas Punt) Hey Zeev=2C=0A= =0A= > Another change being considered and not yet in the RFC is re-allowing=0A= > leading and trailing spaces for numeric strings (sorry Paddy.)=0A= =0A= I think that rejecting leading and trailing spaces for stringy ints is for = the best.=0A= If I only want to accept an integer (in either int or string form)=2C then = by enabling=0A= spaces in that input=2C it would destroy the overall usability of it.=0A= =0A= One scenario I have in mind for this is validating $_GET information for a = RESTful web=0A= service. Having potentially an infinite=A0number of URIs that all point to = the same resource=0A= isn't good:=0A= =0A= /users/1=0A= /users/%201=0A= /users/1%20=0A= /users/%201%20=0A= /users/%201%20%20=0A= etc.=0A= =0A= In this case=2C I don't want to accept any leading or trailing spaces for t= he user ID. So I=0A= would therefore not be able to use an=A0`int` type hint because its accepta= nce rules would=0A= be too lax.=0A= =0A= If spaces are not accepted in stringy ints=2C and I want to pass a stringy = int that may have=0A= leading or trailing spaces in it=2C then I know I can=A0simply apply a trim= () to it before passing=0A= it into a function that's expecting only an int. This way=2C the usability = of integer-only inputs=0A= (as string or ints) isn't compromised by the rules being too weak.=0A= =0A= > The takeaway from this seems to be that the approach of tightening the=0A= > existing rule-set and applying it to both internal functions and new=0A= > user-land code is viable=2C and does not cause the sky to come down falli= ng.=0A= > Preliminary tests suggest it actually finds real potential problems.=0A= >=0A= > More tomorrow.=0A= =0A= Overall=2C a big +1 on this though! The type coercion rules at the moment a= re far=0A= too lax to be considered useful in most situations IMO.=0A= =0A= > Zeev=0A= =0A= Thanks=2C=0A= Tom =