Tous les articles par Jean Molliné

RFC: Unicode Codepoint Escape Syntax

Cette RFC proposait de permettre l’utilisation de séquences Unicode dans les chaînes de caractères (à double-guillemets et heredoc) de PHP.

$str = "Un caractère unicode : \u{1F602}";
Exemple

La RFC proposait d’autres exemples et expliquait pourquoi il avait été choisi de positionner { et } autour du code du caractère : lisibilité et pas de limite en dur au nombre de caractères attendus pour spécifier le code.

Les votes se sont tenus du 8 décembre 2014 au 18 décembre 2014 et nous avons exprimé notre opinion positive sur internals@.
La RFC a été adoptée à 23 voix contre 2.

RFC: ZPP Failure on Overflow

Aujourd’hui, lorsqu’un nombre flottant trop grand pour tenir dans les valeurs supportées pour les entiers est passé en paramètre d’une fonction interne (fonction exposée par PHP ou une extension PHP) qui attend un entier, il est reçu par la fonction sous la forme… d’un entier… ce qui entraîne une perte d’information.

Note technique : une fonction interne spécifie de quel type (au sens C du terme, donc avec du typage strict) chaque paramètre reçu doit être. Il n’y a pas, en C, de type fourre-tout comme c’est le cas pour les variables de PHP, avec utilisation automatique de flottants lorsque des nombres sont trop grands pour tenir sur des entiers.

Cette RFC proposait donc que, dans le cas où un paramètre entier est attendu et que la valeur reçue est un flottant trop grand pour tenir dans un entier, l’analyse des paramètres de la fonction interne appelée échoue, que la fonction retourne sans s’exécuter, et qu’un avertissement soit levé.

Impact pour les utilisateurs de PHP : appeler une fonction interne attendant un entier en passant une valeur trop grande pour tenir dans un entier entraînera la levée d’un avertissement et la non-exécution de la fonction — au lieu de son exécution avec une valeur tronquée.

Cette RFC visait la version 7 de PHP.

Les votes ont été ouverts le 2 Décembre 2014 et on été clos le 12 décembre 2014. Cette RFC touchant plus à de l’implémentation qu’à des fonctionnalités, nous avons timidement exprimé notre opinion sur internals@, en considérant qu’il valait mieux un avertissement clair qu’un comportement étrange.
La RFC a été adoptée à l’unanimité (16 pour, 0 contre).

RFC: Filtered unserialize()

Cette RFC partait de l’idée que la dé-sérialisation de données n’est pas sûre, puisqu’il est, dans certains cas, possible d’injecter du code qui pourrait être automatiquement exécuté (par le destructeur de classe, par exemple) — bien sûr, cela suppose qu’on essaye de dé-sérialiser des données provenant d’une source non réellement sûre (ce que font probablement certaines applications).

Elle proposait donc de modifier la fonction unserialize() de PHP pour permettre d’interdire la dé-sérialisation d’objets ou de limiter celle-ci à un ensemble de classes listées.

Dans le cas où on essayerait de dé-sérialiser un objet non autorisé, on obtiendrait en retour une instance de classe incomplète, comme lorsqu’on essaye de dé-sérialiser un objet dont la classe n’existe pas.

Exemples :

// ceci va tout dé-sérialiser comme auparavant
$data = unserialize($foo);
// Ceci va convertir tous les objets en objets __PHP_Incomplete_Class
$data = unserialize($foo, ["allowed_classes" => false]);
// Ceci va convertir tous les objets à l'exception des instances de MyClass et de MyClass2 en objets __PHP_Incomplete_Class
$data = unserialize($foo, ["allowed_classes" => ["MyClass", "MyClass2"]);
// Ceci va accepter toutes les classes comme étant par défaut
$data = unserialize($foo, ["allowed_classes" => true]);

Les votes ont été ouverts le 3 novembre 2014 et ont été clos le 10 novembre 2014. Considérant qu’apporter un niveau de sécurité lors de la dé-sérialisation de données ne pouvait être que bénéfique, nous avons posté en ce sens sur internals@.
Cette RFC a été adoptée par 17 votes contre 6.

RFC: Safe Casting Functions

Cette RFC partait du constat que les opérateurs de transtypage existant, explicites, n’échouent jamais et ne lèvent jamais d’erreur — ce qui peut être dangereux (surtout s’ils sont utilisés sur des saisies utilisateurs), puisqu’ils retourneront un peu n’importe quoi si les données sur lesquelles on les utilise correspondent elles-mêmes à un peu n’importe quoi.

Elle proposait donc d’ajouter trois fonctions, qui auraient validé leur entrée, au lieu de transtyper aveuglément. Initialement, elles auraient retourné false en cas d’erreur (ce retour aurait pu être soumis à un vote complémentaire) :

  • to_int() : n’aurait accepté que des entiers, des flottants contenant des entiers et pouvant être représentés par des entiers, ou des chaînes contenant la représentation textuelle d’entiers.
  • to_float() : n’aurait accepté que des flottants, des entiers et des chaînes représentant des flottants.
  • to_string() : n’aurait accepté que des chaînes, des entiers, des flottants et des objets transtypables en chaînes.

La RFC entre plus en détail sur le pourquoi de pas mal de choix et donne un long tableau d’exemples.

Les votes ont été ouverts le 19 novembre 2014 et ont été clos le 29 novembre 2014. Nous avons posté un timide +0.5 sur internals@, en considérant que ces fonctions n’allaient pas assez loin vers un réel typage plus strict.
Cette RFC a finalement été rejetée par 16 votes contre 5.