February 2014 on internals@php

March 20, 2014php, internals@, english
 This has been written a few years ago and might not be up-to-date…

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!

BTW, here’s the RSS feed of the posts I might write in English – oh, and if you know someone at planet-php and feel these posts have their place there, feel free to point them to this blog ;-).

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):

Number of mails on internals@ these last three years

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.

Tjerk Meesters indicated the RFC: Power Operator has passed, with 22 votes “for” and 9 votes “against”. As a consequence, PHP 5.6 will have a new power operator symbolized by **:

~/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.

Pádraic Brady then posted a link to the RFC: Escaper for PHP Core, which is a bit older but was going farther. Anyway, though, htmlentities()’s goal is not to deal with just all situations.

Votes on this first RFC have been opened in the middle of the month – and, without much surprise considering the discussions, it has been rejected with 4 votes “for” and 10 votes “against”.

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.

Of course, the idea of Comparable did come back on the stage during the discussion.

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 version_compare().

In the end, the idea has been dropped, as the RFC: Expectations, on which Joe Watkins kept working, answers this (amongst others) needs.

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.

Daniel Lowrey kept working on the RFC: Improved TLS Defaults. It has been opened to votes in the middle of the month. With 16 votes “for” an no vote “against”, this RFC passed for PHP 5.6!

Votes have been opened on the RFC: __debugInfo(). With 23 votes “for” and 3 votes “against”, this RFC passed and this new magic method will arrive with PHP 5.6!

The RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and 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.

Votes on the RFC: Automatic property initialization had been opened the very last day of January. With 11 votes “against” and 7 votes “for”, it has been rejected.

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.

Right at the end of the month, Philip Sturgeon opened votes on the RFC: Array Of – which means we’ll seen the results next month!

internals@lists.php.net 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 news://news.php.net/php.internals.