On 25/04/2019 08:15, Nikita Popov wrote:
The advantage of such an approach would be that no source code leakage could occur when switching to PHP 7.4 or PHP 8.0. The disadvantage is that we'll only be able to fully remove short tags support at a later point in time.
It is certainly my opinion that *IF* short open tags are to be removed, it makes significantly more sense to fail-safe with a compiler error, than it does to fail-unsafe with potential code/data exposure.
If the operations guys or devops want to explicitly remove the safety net with full knowledge of the consequences, on their own heads be it.
Without wanting to seem too melodramatic, the behaviour of the already-passed RFC could lead to code and data leakage, identity theft, even complete server compromise.
People could quite literally lose their livelihoods because of this change, and companies could be compromised in a way from which they could never recover.
IMO PHP as an language is likely to suffer significant reputational damage as a result.
It *shouldn't* happen of course, because engineers and operations should be going line-by-line through the change logs and checking their entire codebase against each one. But we all know that's not how the real world works.
For all those reasons, I am in favour of your proposal to fail-safe with a compiler error.
(Also: Did I miss a vote option which would have made short_open_tags always on?)
-- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
