Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114909
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
In-Reply-To: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
Date: Wed, 16 Jun 2021 18:24:46 +0100
Message-ID: <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e4222f05c4e55e47"
Subject: Re: [RFC] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000e4222f05c4e55e47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 12 Jun 2021 at 18:00, Craig Francis <craig@craigfrancis.co.uk>
wrote:

> I'd like to start the discussion on the is_literal() RFC:
> https://wiki.php.net/rfc/is_literal
>



Hi Internals,

Following up on the is_literal() RFC, thanks for the feedback. It looks
like there are only 2 minor open issues - updating the implementation to
allow integers, and what to call the flag/function.

Matthew Brown wants to support integer values, simply because so much code
already includes them, and I cannot find a single way that integers alone
can cause issues from an Injection Vulnerability point of view (but if
anyone can, I absolutely welcome their input). Other variable types like
floats and booleans will still be excluded (because the value you put in
often is not what you get out, e.g. true/TRUE being converted to "1").

Which leads us to the name, because "is_literal" may be, uh, too literal.
So can we come up with something better?

It needs to be a name that suggests: This variable contains programmer
defined strings, integers, and interned values (as noticed by Claude Pache
and Rowan Tommins). Ideally staying in the standard convention of
=E2=80=98is_singleword=E2=80=99.

Joe has suggested is_known(), where "we have the concept of known strings
internally", which I like (though might clash with more userland functions
than =E2=80=98is_literal=E2=80=99). Last night I also wondered about `is_co=
nstrained()`, as
the value has limited sources. But I'd also welcome more suggestions, and
am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion)=
.

I've also updated the RFC Future Scope to note how this could be a
dedicated type (thanks someniatko, Matthew Brown, and Dik Takken); and I'm
really impressed to see the addition to Psalm so quickly.

Craig

--000000000000e4222f05c4e55e47--