> Le 15 juin 2021 à 09:19, Joe Watkins <krak...@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
