Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86054
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <554176D6.2030007@gmx.de>
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>
 <554176D6.2030007@gmx.de>
Date: Thu, 30 Apr 2015 10:24:23 +0900
Message-ID: <CAGa2bXaPjvkFYtkhRM1JisSvxgR0v8adkD_P_zkUng4xfBWFHg@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Ryan Pallas <derokorian@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb1ef2c1bf4dc0514e6f736
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--e89a8fb1ef2c1bf4dc0514e6f736
Content-Type: text/plain; charset=UTF-8

Hi Christoph,

On Thu, Apr 30, 2015 at 9:27 AM, Christoph Becker <cmbecker69@gmx.de> wrote:

> > On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev <smalyshev@gmail.com
> >
> > wrote:
> >
> >> PHP types are not machine native types. But yes, it forces PHP type -
> >> that's why it is *type* check.
> >
> > Type hint is better to stay as "hint" under weak mode. IMO.
>
> "Type hints" have never been hints.  The wording is a misnomer.  Try to
> pass an int to a parameter declared as array, for instance.
>

I understand how it worked and how it will.
"hint" sounds a little misleading. Since we named it already, we may follow
the semantics.


>
> >> You are saying type checking which produces fatal errors does not match
> >> your use case. OK, I can sympathize, but how introducing more
> >> pseudo-types helps? You just fix one narrow use case that you have right
> >> now while leaving the problem still in the same place. That's not a good
> >> way to address it.
> >
> > I'm not concerning myself, but I'm worrying about users to write
> > apps/libraries
> > that can cause DoS easily. I don't want to see my my apps emit fatal
> error
> > by upgrading library just because library author decided to use type hint
> > wrongly.
>
> A fatal error wouldn't constitute a DoS vulnerability, would it?
>

Attacker may inject huge ID value and/or they may simply access
web sites to reach 2 billion limit, for example.


>
> > BTW, GMP integer is already integrated into PHP why not treat GMP as int?
> > It's type "hint", isn't it?
>
> The basic idea of the STHs is to guarantee that the value is of the
> respective type inside the function (parameter type "hints") resp. the
> return value (return value type "hints") has the respective type.
>
> Accepting GMP for int just won't fit to this definition -- or it would
> lead to a potentially considerable data loss.


I mean accept GMP as PHP int in weak mode as it is, not converting C int.
Strictly speaking GMP has its type, but it can be used as "string integer"
now.
i.e. $gmp_int_a + $gmp_int_b works just like $str_int_a + $str_int_b.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--e89a8fb1ef2c1bf4dc0514e6f736--