Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <3844e0dd17eef0f8991dd01eda533e2e.squirrel@webmail.klapt.com>
Date: Wed, 19 Nov 2014 14:49:39 +0000
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1433D80F-85DF-45A9-B9E8-2E48E0B6321C@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <CAGa2bXY4P9dP6rB0-hZ9E5=ALQv+04s157BtwyF7_N3VZV8igA@mail.gmail.com> <656B2A54-572B-4E6A-892B-25FAE428F434@ajf.me> <3844e0dd17eef0f8991dd01eda533e2e.squirrel@webmail.klapt.com>
To: Anatol Belski <anatol.php@belski.net>
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 19 Nov 2014, at 08:33, Anatol Belski <anatol.php@belski.net> wrote:
>=20
> while briefly looking through the conversion examples, i see some =
weird
> results
>=20
> string(5) =E2=80=9C31e+7=E2=80=9D - shouldn't this be valid for int?

The trend seems to be to consider things with exponents or decimal =
points as floats. Even though there=E2=80=99s a case for supporting it =
for ints, (int) and intval() don=E2=80=99t work with exponents, so =
to_int() shouldn=E2=80=99t either.

> string(4) =E2=80=9C0x10=E2=80=9D - hex, but that's int, no?

Supporting hex is a rather obscure use-case. Also, (int) and intval() =
don=E2=80=99t support it.

> string(3) =E2=80=9C010=E2=80=9D - octal, but that's int, no?

While allowing leading zeroes would be nice, octal causes problems. In =
particular, 0-prefixed strings aren=E2=80=99t handled consistently. Some =
things deal with them as decimal, others deal with them as octal. =
Because the user=E2=80=99s intent isn=E2=80=99t clear, we can=E2=80=99t =
support them, and I assume this is why FILTER_VALIDATE_INT doesn=E2=80=99t=
 support them.

> string(4) =E2=80=9C10.0=E2=80=9D - this would be casting to 10, so int =
valid

Allowing .0 for an int doesn=E2=80=99t feel right. What do we do for =
=E2=80=9C10.01=E2=80=9D? Reject it? That seems rather arbitrary when we =
would be allowing =E2=80=9C10.00=E2=80=9D. So it=E2=80=99s not accepted.

> object(Stringable)#2 (0) {} - and similar actually, what if =
_toString()
> returns some int/float literal? that should pass as well, no?

__toString() always errors if it doesn=E2=80=99t return a string, I see =
no reason to change that.

> Generally I'd say no to this RFC. The current casting is not perfect, =
but
> as for me - the one suggested is highly questionable as well. IMO as =
long
> as there are no proper strict types in PHP, any other rule set for =
casting
> would be just another coordinate system for the same, which isn't =
worth
> while at least.

Something like this RFC is a necessary prerequisite for strict types. =
Without it, there=E2=80=99s not a convenient way to do a safe =
conversion. If we just add strict types, people will blindly use (int) =
or intval() and magically, garbage input will be transformed (through =
the magic of ignoring everything in the string that doesn=E2=80=99t look =
like an int) into apparently sane input and apps will do dangerous =
things when presented with bad user input.

--
Andrea Faulds
http://ajf.me/