Hi,
It's not unpredictable.
krakjoe@Fiji:/opt/src/php-src$ cat nothing.php
<?php
$var = 'not-literal';
var_dump(
$_ENV['var'],
is_literal($_ENV['var']));
?>
krakjoe@Fiji:/opt/src/php-src$ var=not-literal sapi/cli/php nothing.php
string(11) "not-literal"
bool(false)
The engine doesn't intern "randomly", and doesn't intern input.
Cheers
Joe
On Tue, 15 Jun 2021 at 10:56, Claude Pache <claude.pa...@gmail.com> wrote:
>
>
> Le 15 juin 2021 à 09:19, Joe Watkins <krak...@gmail.com> a écrit :
>
> Morning,
>
> https://3v4l.org/nJhc1/rfc#focus=rfc.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.
>
>
> Hi,
>
> I disagree that it is not dangerous. At the very least, it makes
> `is_literal()` unpredictable, therefore unreliable, which is bad. The
> following git is more illustrative of the issue:
>
> https://3v4l.org/SNJDJ/rfc#focus=rfc.literals
>
> The fact that a given string happens to be written literally somewhere
> else in the program doesn’t mean that it is written literally in that
> context. Taking the example from the RFC:
>
> $qb->select('u')
> ->from('User', 'u')
> ->where('u.id = ' . $_GET['id']); // INSECURE
>
> I want that the `$qb->where()` method is able to reliably detect that the
> string provided is not literal, even when it happens by chance that the
> exact same string appears literally somewhere else in my code.
>
> —Claude
>
>
>
