Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105445 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 96740 invoked from network); 25 Apr 2019 13:38:05 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 25 Apr 2019 13:38:05 -0000 To: internals@lists.php.net References: Date: Thu, 25 Apr 2019 11:38:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.0.205.114 Subject: Re: Alternative approach to short tags deprecation From: markyr@gmail.com (Mark Randall) Message-ID: 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