Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.178 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXZhUPZ2wvtTP_yYuhVUrhkZTFOHh8vx956jW-8aXEY5ag@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> <CAGa2bXZhUPZ2wvtTP_yYuhVUrhkZTFOHh8vx956jW-8aXEY5ag@mail.gmail.com>
Date: Wed, 24 Jun 2015 14:23:50 +0900
Message-ID: <CAGa2bXZygU1wa8NPeXncNSKh2b-ucCyCO-1jGoLU+4J86fWMXg@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=001a113ac028a4df1605193cb89a
Subject: Re: [PHP-DEV] Optimizing php_html_entities()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113ac028a4df1605193cb89a
Content-Type: text/plain; charset=UTF-8

Hi Anthony,

On Wed, Jun 24, 2015 at 12:00 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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.
>

Another reason of this optimization is type affinity that I would like to
add.

https://wiki.php.net/rfc/introduce-type-affinity

With type affinity, "integer string"/"float string" are converted to
int/float type
and PHP can execute script more efficiently with type hint. i.e. Type
affinity
eliminates countless "string" -> "int/float" conversions with weak type
hint.

Issue with converted values is int/float cannot escape as it is now because
they expect "string" strictly with "strict_types=1", as well as it requires
needless type conversions to "string" in weak mode.
e.g. htmlspecialchars, pg_escape_string/identifier/literal, etc.
Therefore, I would like to allow int/float for these functions.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113ac028a4df1605193cb89a--