Am 10.09.2014 um 03:32 schrieb Andrea Faulds:
But then I’ve thought more about it. I’m usually OK with certain BC breaks, I
just don’t like this specific one. It doesn’t affect me, but, well, I don’t see
the point. It doesn’t really help language consistency or anything, (OK, sure,
only two sets of delimeters now, but it’s not a big deal like some other things
are), and you’ll force people to update every file in their codebase if they’re
affected, assuming people who use alternative tags use them everywhere. There’s
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 instead of the
output, which might include configuration details like database passwords or
password hash salts. It’s also possible that people won’t notice this is
happening if they only used these alternative tags in a few obscure places.
I wonder if, really, we might be better off keeping them around and just
outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7
deprecate them.
Hi,
I didn't even know that these tags exist ;-)
If you check Github you will see round about 10.000 code results, but
most of them are tests (.phpt), example files, duplicate results, and
maybe <100 projects that really use them, and I would guess >90% of
these projects are rarely used and very old.
https://github.com/search?p=1&q=%22%3Cscript+language%3Dphp%3E%22&ref=searchresults&type=Code
Does the removal of those two tags result in a tiny performance boost,
or have any other "real" advantage besides a little less code in php-src?
In my opinion we should remove them, but before doing that they should
be deprecated for at least a year, and spread the word. I also see the
problem of presenting the sourcecode as cleartext to website users.
Maybe it makes sense to have a version after the deprecation period
which just stops the PHP parser/compiler and stops working on that file,
something like a FATAL error without exposing the file content?
Maybe there is a way to automatically create Github Issues where one of
these tags is found in a repository?
I don't know if that's common, but Webhosters and PHP PaaS Providers
COULD scan their customers code for these tags and inform them about the
potential security problem before they upgrade to PHP 7 (where these
tags are removed)?
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
