> Le 15 juin 2021 à 09:19, Joe Watkins <krakjoe@gmail.com> a écrit :
>
> Morning,
>
> https://3v4l.org/nJhc1/rfc#focus=rfc.literals
> <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
<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