Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115178
MIME-Version: 1.0
Date: Mon, 28 Jun 2021 17:21:09 +0100
Message-ID: <CAFv4g+Fh=V-vNAmv_oM3yErpsd4+K3oqxHDsN+wvc8U2DkKsHQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002e57a005c5d5e15e"
Subject: is_literal() compile-time awkwardness
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000002e57a005c5d5e15e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Internals,

There=E2=80=99s an awkward hitch with removing integer support. Fair warnin=
g, we=E2=80=99re
about to get into some under the hood stuff:

During the compilation process (before any user data is involved), PHP
makes tiny optimisations to code e.g. `=E2=80=9Da=E2=80=9D . 1` becomes `=
=E2=80=9Da1=E2=80=9D`. In the
parts where this happens, the developer-defined values (strings, integers,
floats and booleans) are - technically accurately, but erroneously since we
aren=E2=80=99t doing full =E2=80=99developer-defined=E2=80=99 support - tre=
ated as literal values,
and when concatenated the string gets (correctly, but erroneously) flagged
as a literal.

So, for example, a developer may wonder why $b is seen as a non-literal,
whereas $c is flagged as a literal:

$a =3D 1;
$b =3D "Hello " . $a;  // Non-Literal

$c =3D "Hello " . 1;  // Flagged Literal

This is because $b involves concatenation at run-time, and because $a is an
integer, it=E2=80=99s seen as a non-literal. Whereas $c has its value optim=
ised by
the compiler into a single literal string, so it=E2=80=99s marked as litera=
l.

Or for a second example, where the compiler can "coerce" an integer into a
string:

$a =3D "Hello ";
$b =3D $a . 2;

The compiler cannot do an optimisation based on the contents of $a, but it
can see that $a will be concatenated with the integer 2. To optimise this,
the compiler will coerce that integer into the string =E2=80=9C2=E2=80=9D, =
to make the
concatenation faster at runtime, so $b will be seen as a literal, which the
developer may find odd, due to the presence of the developer-defined
integer.

Now these aren=E2=80=99t security issues, and it doesn=E2=80=99t work the o=
ther way round:
`is_literal()` doesn't incorrectly report any user (non-literal) data as a
literal. But nonetheless it is still technically inconsistent - as it looks
like it accepts =E2=80=98literal integers=E2=80=99 at some points and not o=
thers.

(And hence why when we were including integer support this was fine -
because it simply accepted integers too and so it was all consistent. As it
is, the list feedback was to not include them, as it=E2=80=99s not possible=
 to
include a flag on integers to say if they are developer defined or not in
the same way we can with strings).

OPcache adds its own similar twist if it=E2=80=99s enabled, but with the ad=
ded fun
that unlike PHP=E2=80=99s own optimisation processes, OPcache is by its nat=
ure
inconsistent when it runs, changing what it optimises and when based on a
number of factors (e.g. available memory) and so isn=E2=80=99t guaranteed t=
o
optimise the code every time.

As to the specific issue, if you have:

$a =3D implode("-", [1, 2, 3]);

The variable $a will be set to "1-2-3", as a non-literal (because of the
use of integers).

However, if the OPcache is enabled, it can make its own optimisation,
performing the implode() call early, and storing the literal string "1-2-3"
in the OPcache, so the implode() function does not get used at runtime. In
effect the compiled script becomes:

$a =3D "1-2-3"; // Flagged as literal

(Which as before, may be =E2=80=99literally=E2=80=99 correct but since it=
=E2=80=99s not supposed to
support integers=E2=80=A6)

Or the OPcache while enabled doesn=E2=80=99t optimise it this time (because=
 it=E2=80=99s
not guaranteed to), and leaves it as the previous example and *ding*
non-literal sighted.

Now while I imagine most people checking `is_literal()` would, on seeing an
=E2=80=98error=E2=80=99 like that, simply go to their code, realise there i=
s an integer in
it, and then change it without any further interest, but it might still
cause them confusion if they wondered why they hadn=E2=80=99t seen the erro=
r every
time before.

Any thoughts?

Craig

--0000000000002e57a005c5d5e15e--