Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114877
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <C2605471-8EC9-4C36-88D4-E98F5C291BCF@gmail.com>
In-Reply-To: <C2605471-8EC9-4C36-88D4-E98F5C291BCF@gmail.com>
Date: Tue, 15 Jun 2021 09:19:01 +0200
Message-ID: <CAOwTYAu2hQaJYM4mJN0DDYmPhP9BHcnrxM1f459wKa-jj1TnDg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Craig Francis <craig@craigfrancis.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000075f00605c4c8cae7"
Subject: Re: [PHP-DEV] [RFC] is_literal
From: krakjoe@gmail.com (Joe Watkins)

--00000000000075f00605c4c8cae7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Morning,

https://3v4l.org/nJhc1/rfc#focus=3Drfc.literals

It's not so much a bug as a side effect or quirk.

Note that, the result is correct, in the sense that you do have a literal
string - it is not marking an unsafe string as safe.

It's just that existing implementation details - RETURN_CHAR using interned
strings, and literal constant strings being interned by the compiler - lead
to a literal string being "re-used".

This is just a natural consequence of literal strings retaining their
literalness in the way we want them too, nothing dangerous is going on.

Cheers
Joe


On Tue, 15 Jun 2021 at 00:32, Claude Pache <claude.pache@gmail.com> wrote:

>
>
> Le 12 juin 2021 =C3=A0 19:00, Craig Francis <craig@craigfrancis.co.uk> a
> =C3=A9crit :
>
> =EF=BB=BFHi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
>
> Hi,
>
> I=E2=80=99ve found an interesting bug in the implementation:
>
> https://3v4l.org/JfSHX/rfc#rfc.literals
>
> =E2=80=94Claude
>
>
>

--00000000000075f00605c4c8cae7--