Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115184
MIME-Version: 1.0
References: <CAFv4g+Fh=V-vNAmv_oM3yErpsd4+K3oqxHDsN+wvc8U2DkKsHQ@mail.gmail.com>
In-Reply-To: <CAFv4g+Fh=V-vNAmv_oM3yErpsd4+K3oqxHDsN+wvc8U2DkKsHQ@mail.gmail.com>
Date: Mon, 28 Jun 2021 20:53:33 +0300
Message-ID: <CA+hqhpdTjXdjy8bqhTZi6RQJdvQRCLg63s4Cep3VM3dr-a2x0w@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] is_literal() compile-time awkwardness
From: weirdan@gmail.com (Bruce Weirdan)

On Mon, Jun 28, 2021 at 7:21 PM Craig Francis <craig@craigfrancis.co.uk> wr=
ote:

> There=E2=80=99s an awkward hitch with removing integer support.

Correct me if I'm wrong, but all those inconsistencies would happen
even if all integers were considered literal, e.g.
https://3v4l.org/C9YpE/vld#output clearly performed compile-time
concatenation with a float.

> Now these aren=E2=80=99t security issues, and it doesn=E2=80=99t work the=
 other way round:
> `is_literal()` doesn't incorrectly report any user (non-literal) data as =
a
> literal.

I'd say it's fine that way.

> OPcache adds its own similar twist if it=E2=80=99s enabled, but with the =
added fun
> that unlike PHP=E2=80=99s own optimisation processes, OPcache is by its n=
ature
> 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=
 to
> optimise the code every time.

Now that's a problem. If the same code produces different results for
expression literalness depending on external factors like available
memory it may pass in the test environment, but fail in production.


--=20
  Best regards,
      Bruce Weirdan                                     mailto:weirdan@gmai=
l.com