Re: [RFC] New operator for context-dependent escaping

> But you still have to rember to use <?* instead of <?= and use the > proper escaping function. I see no problem if companies make a rule not to deploy code containing "<?=". I've seen similar rules for eval() and other functions. Using proper escaping function is surely another challenge which can be source of security bugs, maybe someone brings up a fuzzy generator to detect these things. > I just wanted to give an explanation why I would vote > against it. I'm not sure if it is a good thing to vote against security enhancements. Regards Thomas Christoph Becker wrote on 24.07.2016 18:52: > On 24.07.2016 at 18:21, Thomas Bley wrote: > >>> <?* $str ?> >>> >>> instead of >>> >>> <?=h($str)?> >> >> benefits are using static code analyzers, grep "<?=" for code reviews, etc. > > Well, something like grep -P <\?=(?!h[(]) seems to be a > viable > alternative. > >> Having function names with single characters is bad taste and only useful for >> obfuscating. > > Cryptic "operators", however, are not? > >> The big difference is: >> With <?*, you have to define an escaping function, with <?= it's optional. > > But you still have to rember to use <?* instead of <?= and use the > proper escaping function. > > Actually, I'm not really interested in discussing the current RFC (the > discussion is already rather lengthy, and has started to go in circles > long ago). I just wanted to give an explanation why I would vote > against it. > > -- > Christoph M. Becker >