Cet article est aussi disponible en français.
I’ve been doing a monthly digest of what happens on
internals@ for more than a year now, each time in French. Every now and then, some people said it would be nice to have it in English too… So, after december 2013 and last month, here’s my third shot at this!
2014 keeps going on, with a busy month of february: 972 mails have been sent to the
internals@ PHP’s mailing-list – which is pretty much the same number as the previous month!
As a graph representing the number of mails per month for the last three years, we’d get (the full history since 1998 is available here):
Right in the middle of this month, PHP 5.6-
alpha2 has been released.
Two weeks later, Ferenc Kovacs announced the
alpha3 version (tagged at the end of the month) would be followed by the first beta version, arround the middle of march – which leaves two weeks to merge features that are still under work to PHP 5.6, as the beginning of the beta versions phase means PHP 5.6 reaches its feature-freeze.
As the release of PHP 5.6 gets closer, the idea of a future major version, maybe « PHP 6 » (or maybe « PHP 5++ », as the sole fact of choosing a version number might require a serious debate), has been evoked more and more frequently those last few months. The old todo:php60 wiki page has even been re-linked to, even if it would be nice to not lose its history.
One of the most important point seems to be Unicode: generally speaking, pretty much everyone seems to agree that PHP 6 will have to support Unicode. Still, how is a real question! A few links on the matter, as well as a summary, have been posted. A first step, at least while developping, might be to use a flag « supports UTF-8 » that would be used by all functions modified to deal with Unicode – while the others would still work by bytes as they do today.
Pierre Joye said he had put his ideas for PHP 6 on paper: ideas:php6. This page aims to summarize propositions about which it should be interesting to discuss or work in greater details. Stas Malyshev answered with his own list, followed by Julien Pauli and some others.
In the same time, Marc Bennewitz asked if PHP 6 would not be an occasion to remove the
resource type, even if it means transforming it to a
Resource class. In effect, as noted by Chris Wright, resources feel like an odd way to work with objects, and converting as many as possible to specific classes might often give developpers an easier way to find out what kind of data a resource actually references.
~/bin/php-5.6-debug/bin/php -a Interactive shell php > printf("2 ** 3 = %d\n", 2 ** 3); 2 ** 3 = 8
Following several discussions on previous weeks, Rouven Weßling opened votes on RFC: Timing attack safe string comparison function.
Of course, the proposed
hash_compare() name didn’t get unanimous approval, but no other proposal did either – and the discussions have been going on since the middle of December. In parallel, Yasuo Ohgaki noted that, as timing attacks are already possible today, it might be good to add this new function to existing versions of PHP, without waiting for PHP 5.6.
In the end, the idea behind this RFC passed with 22 votes « for » and 1 vote « against ». As the implementation has not been fully choosen yet, it is not sure whether
hash_compare() will arrive for PHP 5.6 or 5.7 – this function being quite sensitive, its implementation being discussed after the idea has been accepted is not surprising.
After a long discussion about the
uniqid() function, which generates an unsafe random number, Yasuo Ohgaki announced the RFC: Build OpenSSL Module by Default, suggesting always including
openssl. Jan Ehrhardt answered with a link to the new
crypto extension that acts as a wrapper arround OpenSSL’s encryption library.
At the same time, Thomas Hruska proposed to include
mcrypt_create_iv() to PHP itself – as a name like
rand_bytes() – so we don’t depend on an extension, not always enabled, to generate a safe random piece of data.
After this, Pierre Joye posted about his idea of adding two new configuration options to unify the source of entropy used by the relevant PHP functions. As noted by Pádraic Brady, a good approach would be to set up a new dedicated API, but there is no time to do that before the release of PHP 5.6 – on the other hand, for PHP 6… Nikita Popov then posted a few clarifications about that suggestion. And the RFC: Unify crypt source INI settings has arrived a few days later.
Yasuo Ohgaki has written the RFC: Improve HTML escape. This being said, as noted by Stas Malyshev later,
htmlentities() is not built to escape attributes not enclosed in quotes – which are valid in HTML5.
Davey Shafik announced the RFC: Combined Comparison (Spaceship) Operator, in which he suggested we could add a new
<=> operator that would return
0 if both its operands are equal,
1 if the one on the left is greater than the other, and
-1 if the greatest one is the one on the right.
The name feels cool, but the question of its usefulness has quickly surfaced. Actually, such an operator could be useful for comparisons in contexts such as sorts – but using a function already does the trick.
Yasuo Ohgaki started a thread about allowing each PHP script to report the minimal version of PHP it needs in order to be executed.
The main interest behind this proposal would be to do that check during the compilation phase instead of the execution one. For now, it’s typically up to the dependancies manager (such as Composer) to deal with this task – and this idea can already be implemented with
Levi Morrison said that one week for the voting phase of some RFCs seemed a bit short for him, as not all developpers regularly work on PHP (and there are holidays here and there) and RFCs sometimes require a bit of thinking. That being said, as quickly answered by Pierre Joye and Andrea Faulds, the voting phase is always preceeded by at least two weeks allowing for discussions.
The RFC: Introduce
session_start() options -
lazy_destroy has too been submitted to voting. With 9 votes « for » and 1 vote « against », the first one of these options has been accepted – while the others have all been rejected.
Yasuo Ohgaki wrote the RFC: Secure Session Module Options/Internal by Default in which he suggested several modifications aiming to enhance the security of PHP’s sessions.
After long discussions started last month, Anatol Belski announced the RFC: 64 bit platform improvements for string length and integer in zval has been rejected. Trying to summarize: the changes are too important (for PHP itself, but also/mainly for extensions) for a minor version like PHP 5.6, and would be better suited for a major version like PHP 6.
Yasuo Ohgaki noticed the RFC: Optional PHP tags by php.ini and CLI options had been discussed a long time ago, and tried to revive the subject. Stas Malyshev quickly answered that such a feature would only cause more pain when dealing with PHP files, as the syntax and its parsing would depend on configuration parameters – and it would also increase risks of code-leakage. After a few days of discussions, Yasuo Ohgaki annouced he dropped that RFC.
firstname.lastname@example.org is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server