Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5541C0E0.2080006@gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
	<55401F31.9030703@gmail.com>
	<CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
	<CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
	<55416849.9010808@gmail.com>
	<CAGa2bXbkCx2Nqb9YBut3id4N=nhjLBGPN8Ucrx7R6mRnGjB2og@mail.gmail.com>
	<5541753D.5050908@gmail.com>
	<CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com>
	<55419C0C.7020207@gmail.com>
	<CAGa2bXaPAwFs=2=wHAE615dhyFO_5sUnKV4X2cMVFJM9xoG1wg@mail.gmail.com>
	<5541C0E0.2080006@gmail.com>
Date: Wed, 29 Apr 2015 22:59:58 -0700
Message-ID: <CAMPTd_AK8sr2EVH38wWmv1LzRp1=ShA2uNon=+cPYukwDUG2LA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Ryan Pallas <derokorian@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493afa3af0730514eaceff
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: walterp@gmail.com (Walter Parker)

--089e01493afa3af0730514eaceff
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > "int" Cast is bad. Incorrect "int" type hint worse as it could trigger
> DoS.
>
> I do not see any potential for DoS here. Trying to assign security
> implications so it looks like disagreeing with you jeopardizes security
> is not a good idea. If your code accepts non-numeric data and puts it to
> functions that except integers without validation, it is bad code and
> "numeric" hint would not help here, as unvalidated data can contain
> anything. If unexpected input causes denial of service in your code, it
> is a code architecture problem, which should not be solved by adding
> stuff to PHP.
>
> > It's not all, but the main issue here is 32 bit CPU & PHP int is too
> > small for
> > database record IDs.
>
> Correct way to go there is treating these IDs as strings or objects and
> having code that handles them properly. If they do not fit PHP int, they
> should not be used with functions that expect int.
>
> > To maximize compatibility, arbitrarily size of int/float like
> > string/value should be
> > accepted as numeric(or int/float).
>
> No, it should not be, since they are neither int nor float.
>

I have to strongly agree with Stanislaw here. If you are getting strings
from the DB because they don't fit in int, leave them as strings. If
someone breaks the code by adding the wrong type hints, then they have
broken the code.

Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life a pain for regular or
better programmers while only adding mild speed bumps to those clever
idiots.

Things like a numeric type will only encourage the clever idiots to write
half broken code.

We just had to fix ZIP codes because the look like integers, so they get
processed and stored as integers. But this can break things when dealing
with New Jersey, which has ZIP codes like 07101. If you drop the lead zero,
then you have a different string/number and it can (and does) cause issues.


Walter

>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--089e01493afa3af0730514eaceff--