Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115133
MIME-Version: 1.0
References: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
 <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> <CAFv4g+EaT309KDWz63j3S7n8E58czEWTKUEw9hAvgt7s6R9eKQ@mail.gmail.com>
 <CAKws9z02yCZTb2_mw-5xUO5-QLc4jbOUcBRfJ8nFSNPP1rgO3g@mail.gmail.com>
 <CA+hqhpfUiOMLDZyXTqP+mm9jjG6v+K94Ug7K_zvuuZus_XhOaQ@mail.gmail.com>
 <CAKws9z34nTT0_CXoo4Yq7zO2CZX622has23xmfHbWjfaDrgLqA@mail.gmail.com>
 <CA+hqhpdR=W8nbWy8UBgLtKdvb_KCss5mpzturS67HhqRj4q6BQ@mail.gmail.com>
 <CAKws9z1=6fmCxJWYVfN+xKT+u=_ZTq0m7C0nZPT6LB5scbfpXQ@mail.gmail.com>
 <95D16F2E-E9DD-4964-A0E2-62E1FB0D976B@koalephant.com> <CAKws9z1M6aLMJ+T7KEAYbEu7N3ufFi8Lsqpr4GP6G06+8aG3SQ@mail.gmail.com>
 <4DE5E2EC-26D6-4D2C-95A9-B843B440EE87@koalephant.com> <CAGBsUrfar+bY+4R9Wp=WfTr5r7-Ur0pVDmNYGJTt1nh9AQ3-Zw@mail.gmail.com>
 <26037CB4-4723-4DC5-BD92-BBDC4F548E17@koalephant.com> <24E12B58-7613-4E67-852C-3312F4AE769C@newclarity.net>
 <CAOwTYAtnib3uWToDxHD5xwHPDq755_xYV4Xte+4UBZQcXA+kow@mail.gmail.com> <CA+kxMuSdY6w4pUGsZgSe8RntjsXEFoa=kBHqFYg9vwmD4zEJ9w@mail.gmail.com>
In-Reply-To: <CA+kxMuSdY6w4pUGsZgSe8RntjsXEFoa=kBHqFYg9vwmD4zEJ9w@mail.gmail.com>
Date: Fri, 25 Jun 2021 00:57:02 +0100
Message-ID: <CAFv4g+GimufiLQ97fuRu=yg6uhwuf2cY1mh_uEveKWcQ8wddeg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003954db05c58bc800"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000003954db05c58bc800
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 24 Jun 2021 at 21:25, Dan Ackroyd <Danack@basereality.com> wrote:

> > Please can you go into some detail about what you think people are
> > meant to do when they detect a non-literal used where a literal is
> > expected?
>
> There is a whole load of hand waving going on of "you can protect
> yourself!" but then no detail of what this RFC proposes people
> actually do, which means people can't evaluate whether it's worth
> adding or not.
>


As noted by Lauri Kentt=C3=A4, "I'd imagine people use custom error handler=
s
which report errors (warnings, notices) to ticket system or email or some
other convenient place, so they don't need to read through logs."

By using a simple function, it allows the library to handle the situation
however it likes. In the RFC there is a "How it can be used by libraries"
link, which shows how a library can easily provide options for a basic
warning, exception, or just ignoring. But a library could also only run
these checks in development mode (off in production), or do additional
checks to see if the value is likely to be an issue (value matches a field
name), etc.

https://github.com/craigfrancis/php-is-literal-rfc/blob/main/justification/=
example.php




> > Why are you prioritising speed of adoption, over reducing the cost of
> > using this feature for projects over say the next 5 or 10 years?
>
> I think this feature should be of most value to teams with large
> code-bases, where maintaining the code (and figuring out security
> problems) has a much higher cost than for small code-bases, where this
> feature might not deliver much value. But by carrying the literal flag
> through on string concat, that results in it being annoying to use for
> teams with large code-bases....which seems self-defeating.
>


As noted by Rowan Tommins, "It would also not solve the problem of the
assertion only triggering in production without a careful integration test.
That can only be solved with a static analyser, which would also have
enough information to isolate the cause."

Static Analysis via `literal-string` is now supported in Psalm (thanks
Matthew Brown):
https://psalm.dev/r/9440908f39

And with a dedicated type (a future RFC, as it needs to cover different
questions that build on this implementation), that would make Static
Analysis even better for debugging, rather than a solution that triggers
exceptions for everyone.

Craig

--0000000000003954db05c58bc800--