Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAAyV7nHX9J8_5X6geOmG9jqCbtxkobsEDBUDEcri0p-TrCRyig@mail.gmail.com>
References: <CAGa2bXa9x_BK9O78N_yvAVj7M5V0UEGsy3ch-VOimaqGaKUA3w@mail.gmail.com>
 <CABBJUpeaVXXJ-JJDP+oHUamuDGwM87Myvm4_0qXAh2cZn8rg3A@mail.gmail.com>
 <CAAyV7nHo2jWSNYL-BQc-yg2SoTzOpNFvcmLNpH9vhL9w3_ab7w@mail.gmail.com>
 <CAGa2bXYRB1Mo6B9WA0knrJ6ziKukaNY18aiYzj-QfvYA+o0VVQ@mail.gmail.com>
 <CAGa2bXa0c5ducwf075MEZEE1psbn2vVHJCzX8p1KC9JJkyEe=Q@mail.gmail.com>
 <CAGa2bXbPrj89krFpY-N+GoC1fW0gKL7EBXBFP5iLUJAWf3mZ1g@mail.gmail.com> <CAAyV7nHX9J8_5X6geOmG9jqCbtxkobsEDBUDEcri0p-TrCRyig@mail.gmail.com>
Date: Wed, 24 Jun 2015 12:00:10 +0900
Message-ID: <CAGa2bXZhUPZ2wvtTP_yYuhVUrhkZTFOHh8vx956jW-8aXEY5ag@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Xinchen Hui <laruence@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0802a0d1672f05193ab6b9
Subject: Re: [PHP-DEV] Optimizing php_html_entities()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--94eb2c0802a0d1672f05193ab6b9
Content-Type: text/plain; charset=UTF-8

Hi Anthony,

On Wed, Jun 24, 2015 at 10:40 AM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> >
> > IMHO, escape/unescape/encode/decode/conversion function is better to
> accept
> > any types.
> > HTML template may be separated script, but database code etc may not.
> >
> > Writing code like
> >
> > <?php
> > declare(strict_types=1);
> > $sql = 'SELECT * FROM '. pg_escape_identifier((string)$table). ' WHERE
> id '.
> > pg_escpae_literal((string)$id).';';
> > pg_query($sql);
> > ?>
> >
> > is better to be avoided. i.e. (string) cast before passing parameter.
>
> I agree 100%. Instead, the developer should get an error if the
> parameter is not a string. Because it is an error. If you're passing
>
an array to `pg_escape_identifier`, you have FAR WORSE problems.
> Having the function accept anything and return anything (as you're
> proposing) would eliminate any ability to detect this problem.
>

I agree 100%.


> If people blind cast, that's their problem. We shouldn't make it
> harder for people to detect problems by blindly accepting anything
> under the sun.
>

strict_types=1 creates issue for int/float which is valid and accepted
without strict_types.

We will have mixed types due to type hint and it's problematic.
If escape functions accept string/int/float/object(only when
it has __toString), it's easier for users. Safety is guaranteed also.

Other than escape/conversion functions that expect "string" type
should get type errors.


> Another example. JSON decode convert numeric to int/float
> >
> > <?php
> > declare(strict_types=1);
> > $data = json_decode($json);
> > $str = mb_convert_kana((string) $data['some_data'], 'AKHV');
> > ?>
> >
> > Are we going to enforce users to use (string) casts for conversion
> functions
> > to switch
> > strict_types=1?
>
> No, the entire point is to have them actually validate the types.


I fully agree.

But people will do this, unless we make conversion functions accept
safe/valid scalars/objects... Or worse, people make assumption that
variables are safe to output w/o escape...

Since there weren't contracts before PHP7, I think we may adjust contract
for some functions before PHP7 release.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--94eb2c0802a0d1672f05193ab6b9--