Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <c8b54c9828154c7e07810461db03bd4d@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>
	<c8b54c9828154c7e07810461db03bd4d@mail.gmail.com>
Date: Sat, 21 Feb 2015 19:56:08 +0000
Message-ID: <CALwr1GmzNOFUgZGxC+vRri6btdh=QQaUnE+d0Wr8XLbQOEuMmQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

On 21 February 2015 at 18:13, Zeev Suraski <zeev@zend.com> wrote:
>> -----Original Message-----
>> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
>> Sent: Saturday, February 21, 2015 8:12 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>>
>> Zeev,
>>
>> First off, thanks for putting forward a proposal. I look forward to a
>> patch
>> that can be experimented with.
>>
>> There are a few concerns that I have about the proposal however:
>>
>> > Proponents of Strict STH cite numerous advantages, primarily around co=
de
>> safety/security. In their view, the conversion rules proposed by Dynamic
>> STH
>> can easily allow =E2=80=98garbage=E2=80=99 input to be silently converte=
d into arguments
>> that
>> the callee will accept =E2=80=93 but that may, in many cases, hide
>> difficult-to-find
>> bugs or otherwise result in unexpected behavior.
>>
>> I think that's partially mis-stating the concern.
>
> I don't think it is, based

The sentence stresses garbage in too much to read as accurate. To
clarify, there is a) garbage in due to weak coercion and b) a function
being called with a string when the typehint says int. Both are
separate concerns around error detection. Stricter coercion can enable
only one of these two, for example. That's better than neither, of
course! The coercion rules were stricter than I expected based on
previous emails. Stressing one too much might suggest to a reader that
the second concern does not exist.

Other pedantic comment: "numerous" is probably too strong a word
there. The advantages may vary by person, but usually fit within basic
five-finger math. It would be more important to enumerate them rather
than selecting one as primary.

On the RFC rules themselves, a few comments:

1. Happy to see leading/trailing spaces excluded.
2. Rules don't make mention of leading zeroes, e.g. 0003
3. "1E07" might be construed as overly generous assuming we are
excluding stringy integers like hex, oct and binary
4. I'm assuming the stringy ints are rejected?
5. Is ".32" coerced to float or only "0.32"? Merely for clarification.
6. Boolean coercion from other types... Not entirely sure myself.
Completely off the cuff: <=3D0: false, >0:true, floats and strings need
not apply.
7. In string to float, only capital E or also small e?
8. I'll never stop call them "stringy" ints.


Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com