Craig, On Fri, 25 Jun 2021 at 23:21, Craig Francis <cr...@craigfrancis.co.uk> wrote: > > We're going back to the original is_literal() proposal. > > https://wiki.php.net/rfc/is_literal
The RFC still contains carrying the string literal flag through string concatenation, which is still not a good idea. And it still doesn't say what people are meant to do when there is an error. Dan Ackroyd 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? Craig Francis wrote: > By using a simple function, it allows the library to handle > the situation however it likes. That's not an answer to the question. Just saying "you can handle it however you like" skips over the core problem with RFC, which is that by supporting carrying the literal flag through string concatenations, > It allows silly mistakes to slip through and make it to production. As > per https://news-web.php.net/php.internals/114858: > Assume that both UserPreferences and getInfoPanel code is covered by > unit tests. The developer who made that change would run the tests, > see the tests pass and then push their code live. At which point, it > would cause an error in production, as the string returned would not > pass the is_literal check. For is_literal checks, what's going to happen is: * programmer makes a mistake, that isn't caught by a test. * programmer deploys site, and entries about non-literal strings start being written to log files. * someone then needs to remember to check the log files, and pull out the appropriate entries, and make a ticket for them to be investigated. * someone then needs to pick up that ticket, investigate the cause of the non-literal string being used, and trace it back to which module/library is causing it, then update the ticket for someone on that team to fix it. * someone on that team needs to have that ticket prioritised before they start work on it. > I'd really like anyone who is promoting this RFC to answer the > question from https://news-web.php.net/php.internals/115010 : > 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? It's going to take more time to track down an error than it will be to start using the feature. I had planned to use this RFC to prevent XSS attacks, and in it's current state I'm going to get a notice of "There's some userdata in an inappropriate place. Have fun finding it!" because the information about where that user data is in the string will be lost. It's still bizarre to me that the RFC is proposing something that allows mistakes to slip through to production. cheers Dan Ack btw, email or ticketing systems are not an appropriate place to log this type of problem. They could happen on every page load, and so generate hundreds of errors per second. As amusing as it is to look back at the times that I have generated 10,000 error emails per second in the past, I don't want to repeat that experience. Also, I'm going to cross-post this, as it's unreasonable to expect people to read all of the different threads. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
