> Thanks, please add start and end dates for voting.
Done. Voting is open till August 6, but I think the result is already clear)
> but after building I've got segfaults
Probably it is because I didn't add PHP_FE_END at the end of function list.
> My *main* issue with this RFC is that I don't consider it to enhance
> security. Forgetting to call the proper escaping function is as easy as
> forgetting to use <?* instead of <?= or calling an inappropriate
> escape_handler_call().
With such a logic any application is not secure, and any escaping is wrong,
because the user can forget something or call inappropriate function. What
if user wrote {{ str | e }} in Twig template in non-HTML context? Does Twig
not enhance security?
The main problem is with HTML context. With new operator it is easy to
escape a value twice, with standard one it is easy not to escape it.
Users can use new operator instead of standard echo operator, this can be
set as a rule in a code style guide. With standard operator this cannot be
done because somewhere escaping function is required, somewhere not.
Standard operator cannot be removed because of backward compatibility, but
this is not the reason not to add more safer operator.
I have an idea about how to add an escaping without changing the language,
but it will break backward compatibility a little.
It is possible to create an extension, which will override the opcodes for
'bitwise or' with strings and 'echo'.
Echo operator will output only so called 'echo-objects', which are
instances of EchoObject class.
If output value is not an echo-object, it is wrapped into it as 'new
EchoObject($value)'.
Constructions like "$str | $context" become "new EchoObject($str,
$context)".
EchoObject has __toString() method, which will call
escape_handler_call($this->value, $this->context).
$escapedValue = $str | $context; // $escapedValue is EchoObject
echo $escapedValue; // $escapedValue->__toString();
<?= $str ?> // echo new EchoObject($str)
The class is required, because there is no another way how to differ <?=
$str | $context ?> and <?= $str ?> constructions (if $str is already
escaped or not). I'm not sure about performance, but I think it will not be
less than with using template engine.
String constants won't be automatcially escaped, because, as I understand,
any HTML code outside php tags is output as 'echo const_html_string'.
<?= 'test' ?> // won't be wrapped into EchoObject
<?= 'test' | 'html' ?> // will be wrapped into EchoObject
Cases like 'int | string' can be fixed with type casting:
$v1 = 8;
$v2 = '16';
$v3 = $v1 | (int)$v2;
I think, not so many applications use bitwise operations with strings, but
for them some suppressing function could be added.
enable_escaping_echo(false);
$str = '111111' | '222222';
$str = $str ^ '333333';
enable_escaping_echo(true);
The details of implementation of escape_handler_call() can be any, the
global registry for every context (as it was in the RFC) or single callable
(as it is in the RFC), at now it does not matter.
What do you think? Can such extension be added as official extension? I
just have no way to build it for all possible OS and versions.
