Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F005B7B2-9407-4387-826C-E0FFAFE7C8B7@ajf.me>
References: <CAF+90c_V0S6KhCLvkRZEcaQQ-Qv_oNaV9EJ_faOo9ZnVRLXQ0g@mail.gmail.com>
	<3619E7A6-6D76-498D-9082-855DAE937C1E@ajf.me>
	<F005B7B2-9407-4387-826C-E0FFAFE7C8B7@ajf.me>
Date: Fri, 12 Sep 2014 20:08:42 +0200
Message-ID: <CAF+90c_89ZyA+w6zPOgyHE_p402iM_tJTAcL0s6opCF_n1ZDZg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c34d4ce081fb0502e22c9c
Subject: Re: [PHP-DEV] Remove alternative PHP tags
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c34d4ce081fb0502e22c9c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 10, 2014 at 3:32 AM, Andrea Faulds <ajf@ajf.me> wrote:

> I initially thought that I=E2=80=99m not really against removing them rea=
lly, but
> I think we should have a script to convert them first. Because someone,
> somewhere, is gonna need it.
>

I have added a small script for porting prehistoric tags, see
https://wiki.php.net/rfc/remove_alternative_php_tags#porting_tool

But then I=E2=80=99ve thought more about it. I=E2=80=99m usually OK with ce=
rtain BC breaks,
> I just don=E2=80=99t like this specific one. It doesn=E2=80=99t affect me=
, but, well, I
> don=E2=80=99t see the point. It doesn=E2=80=99t really help language cons=
istency or
> anything, (OK, sure, only two sets of delimeters now, but it=E2=80=99s no=
t a big
> deal like some other things are), and you=E2=80=99ll force people to upda=
te every
> file in their codebase if they=E2=80=99re affected, assuming people who u=
se
> alternative tags use them everywhere.


In the context of a recent discussion on this list about the nature of
different BC break, this is the very best BC break that is possible. It is
trivial to detect statically and it is trivial to fix statically. Nobody
needs to "update every file in their codebase" manually.


> There=E2=80=99s also a security issue here. If someone uses PHP 7 with a =
codebase
> that has these alternative tags, your code is now visible to users instea=
d
> of the output, which might include configuration details like database
> passwords or password hash salts. It=E2=80=99s also possible that people =
won=E2=80=99t
> notice this is happening if they only used these alternative tags in a fe=
w
> obscure places.
>

I am amenable to adding the asp_tags option to the
http://lxr.php.net/xref/PHP_TRUNK/main/main.c#2339 list, which will trigger
a fatal error on startup if it is enabled - that should make sure that
anyone using those is aware of the problem (we can also add it to the
deprecated list in 5.7, should we have such a release). Doesn't apply to
<script> of course.

Anyway, to me this seems like a no-brainer. Given the nature of the change
(trivial to detect + fix) this is a lot safer than pretty much all the
other BC breaks we've been talking about (like minor changes to integer
semantics). If we can't do this change, then I don't think there is
anything we *can* change.

Nikita

--001a11c34d4ce081fb0502e22c9c--