Ce mois-ci sur internals@php - Février 2014

This post is also available in english.

L’année 2014 se poursuit avec un mois de février bien rempli, avec 972 messages sur la mailing-list internals@ de PHP – quasiment le même nombre que le mois précédent !

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Tout juste au milieu du mois, PHP 5.6-alpha2 a été publiée.

Deux semaines après, Ferenc Kovacs a annoncé que la version alpha3 (tagguée en fin de mois) serait suivie de la première version bêta aux environs de mi-mars – ce qui devrait laisser deux semaines pour merger les fonctionnalités en cours de travail vers PHP 5.6, la phase de versions bêta correspondant au feature-freeze.

Alors que la sortie de PHP 5.6 se rapproche, l’idée d’une prochaine version majeure, peut-être “PHP 6” (ou peut-être “PHP 5++”, puisque le seul fait de choisir un numéro de version risque de demander une sérieuse discussion), refait de plus en plus souvent surface depuis quelques mois. La vieille page todo:php60 du wiki de PHP a même été ressortie, même s’il vaudrait mieux s’assurer de ne pas perdre son historique.

Un des points majeurs est la gestion de l’Unicode : globalement, tout le monde semble d’accord pour dire que PHP 6 devra gérer l’Unicode. Par contre, comment est une réelle question ! Plusieurs liens sur le sujet ainsi qu’un récapitulatif ont d’ailleurs été postés. Une première étape, au moins pour la phase de développement, serait de passer par un flag “supporte UTF-8” qui serait pris en compte par les fonctions modifiées pour gérer l’Unicode – les autres continuant à travailler par octets comme elles le font aujourd’hui.

Pierre Joye a indiqué qu’il avait mis ses idées à propos de PHP 6 sur papier : ideas:php6. Cette page vise à regrouper les propositions sur lesquelles il estimait intéressant d’échanger ou de travailler plus en profondeur. Stas Malyshev a répondu avec sa propre liste, suivi par Julien Pauli ainsi que d’autres.

Au passage, Marc Bennewitz a demandé si PHP 6 ne serait pas l’occasion de supprimer le type resource, quitte à le transformer en une classe Resource. En effet, comme l’a souligné Chris Wright, les ressources ressemblent à un peu à un moyen tordu de travailler avec des objets, et en convertir autant que possible en classes spécifiques permettrait souvent de déterminer plus facilement ce à quoi correspond une ressource.

Tjerk Meesters a indiqué que la RFC: Power Operator était passée, avec 22 votes “pour” et 9 votes “contre”. PHP 5.6 intégrera donc un nouvel opérateur de puissance symbolisé par ** :

~/bin/php-5.6-debug/bin/php -a
Interactive shell

php > printf("2 ** 3 = %d\n", 2 ** 3);
2 ** 3 = 8

Suite à plusieurs discussions sur les semaines précédentes, Rouven Weßling a annoncé l’ouverture des votes sur la RFC: Timing attack safe string comparison function.

Bien sûr, le nom hash_compare() proposé n’a pas semblé faire l’unanimité, mais aucune proposition faite précédemment n’a non plus convaincu – et la discussion a duré depuis mi-décembre. En parallèle, Yasuo Ohgaki a rapidement fait remarquer que, les timing attacks étant déjà possibles aujourd’hui, il serait d’après lui bon d’inclure cette nouvelle fonction sans attendre PHP 5.6.

Finalement, l’idée derrière cette RFC est passée avec 22 voix “pour” et 1 voix “contre”. Le choix de l’implémentation n’étant pas encore effectué, il n’est pas dit si hash_compare() arrivera pour PHP 5.6 ou 5.7 – cette fonction étant assez sensible, il n’est pas surprenant que sa mise en place soit discutée après que son principe ait été validé.

Suite à une longue discussion autour de la fonction uniqid() qui génère un nombre aléatoire “non-sûr”, Yasuo Ohgaki a annoncé avoir rédigé la RFC: Build OpenSSL Module by Default proposant de systématiquement inclure openssl. Jan Ehrhardt a répondu en postant un lien vers l’extension crypto qui fournit un wrapper autour de la bibliothèque de chiffrement OpenSSL.

En parallèle, Thomas Hruska a proposé d’inclure la fonction mcrypt_create_iv() au cœur de PHP – sous un nom comme rand_bytes() – afin de ne plus dépendre d’une extension, pas toujours activée, pour générer une donnée aléatoire sûre.

Dans la foulée, Pierre Joye a indiqué son souhait d’introduire deux nouvelles directives de configuration visant à unifier la source d’entropie utilisée par les différentes fonctions PHP concernées. Comme noté par Pádraic Brady, l’idéal serait de mettre en place une nouvelle API dédiée, mais cette idée n’est pas réalisable d’ici la sortie de PHP 5.6 – par contre, d’ici PHP 6… Nikita Popov a ensuite posté quelques clarifications quant à cette proposition. Et la RFC: Unify crypt source INI settings est arrivée quelques jours après.

Yasuo Ohgaki a proposé la RFC: Improve HTML escape. Cela dit, comme souligné par Stas Malyshev plus loin dans la conversation, htmlentities() n’est de toute manière pas faite pour échapper des attributs non entourés de guillemets – qui sont valides en HTML5.

Pádraic Brady a ensuite posté un lien vers la RFC: Escaper for PHP Core, qui commence à dater un peu mais allait plus loin. En pratique, d’ailleurs, htmlentities() n’est pas faite pour gérer tous les cas.

Les votes sur cette première RFC ont été ouverts en milieu de mois – et, sans grande surprise considérant les échanges, elle a été rejetée avec 4 votes “pour” et 10 votes “contre”.

Davey Shafik a rédigé la RFC: Combined Comparison (Spaceship) Operator, où il proposait l’ajout d’un nouvel opérateur <=> qui retournerait 0 si les deux opérandes sont égales, 1 si celle de gauche est plus grande que l’autre et -1 si c’est celle de droite qui est la plus grande.

Le nom semble cool, mais une question qui s’est rapidement posée est celle d’une réelle utilité. En pratique, un opérateur de ce type serait particulièrement utile pour des comparaisons dans des contextes de tris – mais une fonction fait déjà très bien l’affaire.

Bien sûr, l’idée de Comparable est revenue sur le tapis dans le cours de la discussion.

Yasuo Ohgaki a lancé l’idée que chaque script PHP puisse indiquer de quelle version minimale de PHP il a besoin pour pouvoir être exécuté.

L’intérêt principal de cette proposition serait d’effectuer cette vérification à la compilation plutôt qu’à l’exécution. Pour l’instant, c’est au gestionnaire de dépendances, comme Composer, que revient cette tâche – et cette proposition peut déjà être implémentée à l’aide de version_compare().

Finalement, l’idée a été abandonnée, la RFC: Expectations, sur laquelle Joe Watkins a continué à travailler, répondant (entre autres) à ce besoin.

Levi Morrison a noté qu’une durée d’une semaine pour la phase de vote de certaines RFC lui semblait court, tous les développeurs n’intervenant pas de manière très regulière sur PHP (sans compter les plages de vacances) et les RFC demandant parfois du temps de réflexion. Cela dit, comme rapidement répondu par Pierre Joye et Andrea Faulds, l’ouverture de la phase de votes est systématiquement précédée d’au moins deux semaines de discussions.

Daniel Lowrey a continué son travail sur la RFC: Improved TLS Defaults. Elle a été ouvertes aux votes en milieu de mois. Et avec 16 votes “pour” et aucun vote “contre”, cette RFC est passée pour PHP 5.6 !

Les votes ont été ouverts sur la RFC: __debugInfo(). Avec 23 votes pour et 3 votes contre, cette RFC est passée et cette nouvelle méthode magique sera présente dès PHP 5.6 !

La RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy a elle aussi été soumise aux votes. Avec 9 votes “pour” et 1 vote “contre”, la première de ces options a été acceptée – les autres étant toutes rejetées.

Yasuo Ohgaki a rédigé la RFC: Secure Session Module Options/Internal by Default où il proposait différentes modifications visant à améliorer la sécurité des sessions fournies par PHP.

Les votes sur la PHP: rfc:automatic_property_initialization avaient été ouverts le tout dernier jour de janvier. Avec 11 votes “contre” et 7 votes “pour”, elle a été rejetée.

Après de longues discussions commencées le mois dernier, Anatol Belski a annoncé que la RFC: 64 bit platform improvements for string length and integer in zval avait été rejetée. Pour résumer, cette modification est trop impactante (au niveau de PHP, mais aussi/surtout au niveau des extensions) pour une version mineure comme PHP 5.6, et aurait plus sa place dans une version majeure comme PHP 6.

Yasuo Ohgaki a noté que la RFC: Optional PHP tags by php.ini and CLI options avait été discutée il y a fort longtemps, et a essayé de relancer le sujet. Stas Malyshev a rapidement répondu qu’une telle proposition ne rendrait que plus difficile la gestion de fichiers PHP, puisque la syntaxe et son analyse dépendrait de paramètres de configuration – sans compter que cela augmenterait les risques de fuite de code-source. Après quelques jours de discussion, Yasuo Ohgaki a annoncé qu’il abandonnait cette RFC.

En toute fin de mois, Philip Sturgeon a ouvert les votes sur la RFC: Array Of – à suivre le mois prochain, donc !

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.