Le comité du langage C++ travaille depuis plusieurs années sur des moyens d’améliorer la sécurité mémoire du langage, souvent critiqué pour ses vulnérabilités. En parallèle, Rust est devenu un modèle en matière de sûreté grâce à ses propriétés et son système de vérification stricte des accès mémoire. Le projet Safe C++ visait à créer un sous-ensemble du langage garantissant « une sécurité mémoire comparable à celle de Rust ». Mais la proposition vient d'être mise de côté, car elle n'est pas populaire auprès du comité. La priorité est donnée aux « Profils », un projet qui vise aussi à améliorer la sécurité du langage C++, mais sans s'inspirer du modèle de Rust.La sécurité des logiciels est devenue une priorité pour les développeurs et les organisations du secteur public et privé. Des langages comme Rust, C#, et Go ont gagné en popularité grâce à leurs caractéristiques de sécurité mémoire intégrées. Cependant, le C++ reste un pilier dans le développement de systèmes performants et bas niveau. Pour répondre à cette demande croissante de sécurité, la communauté C++ a élaboré les extensions Safe C++.
Qu’est-ce que les extensions Safe C++ ?
Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.
Le projet Safe C++ est le fruit d’une collaboration entre la C++ Alliance et des ingénieurs renommés comme Sean Baxter. Cette initiative marque une étape importante dans l’écosystème C++, en répondant aux critiques et en s’adaptant aux exigences de sécurité actuelles. Sean Baxter a déclaré que le projet permettrait aux développeurs C++ d'obtenir la sécurité mémoire de Rust, mais sans nécessiter l'apprentissage d'un nouveau langage.
« Safe C++ empêche les utilisateurs d'écrire du code non fiable. Cela inclut des fonctionnalités d'intelligence à la compilation telles que la vérification des emprunts pour éviter les bogues d'utilisation après libération et l'analyse d'initialisation pour la sécurité des types », a-t-il déclaré. Safe C++ permettrait une migration incrémentielle du code, car il ne s'applique qu'au code dans un contexte sécurisé. Le code non sécurisé existant fonctionnerait comme avant.
Abandon de Safe C++ et le choix des « Profils »
Lors de ses dernières discussions, le comité C++ a décidé de mettre la proposition Safe C++ de côté pour concentrer ses efforts sur une autre approche : les « Profils ». Imaginée par Bjarne Stroustrup, le créateur du C++, cette stratégie consiste à définir différents Profils de garanties (sécurité, performance, contraintes de compilation) que les développeurs pourraient appliquer selon leurs besoins, plutôt que d’imposer un modèle de sûreté unique.
« Le groupe de travail sur la sécurité et la sûreté a voté pour donner la priorité aux Profils plutôt qu'à Safe C++. Demandez aux responsables des Profils de vous tenir au courant. Safe C++ n'est pas poursuivi », a commenté Sean Baxter, auteur du compilateur Circle C++ de pointe, en juin de cette année.
Quelles sont les raisons du rejet du modèle Rust-like ? À en croire les discussions sur le sujet, le modèle inspiré de Rust imposait des contraintes jugées trop lourdes pour l’écosystème C++. L’idée d’annoter les fonctions comme sûres ou pures, avec l’obligation qu’elles n’appellent que d’autres fonctions elles-mêmes sûres, a été perçue comme trop radicale et difficilement compatible avec la base de code existante et l’évolution progressive du langage.
Incertitude quant à l'avenir du projet Safe C++
Bien que Sean Baxter affirme que le projet Safe C++ est abandonné, la question ne semble pas totalement trachée. Erich Keane, membre du comité C++ et coprésident du groupe de travail sur l'évolution du C++ (EWG), a déclaré que « la proposition de Sean Baxter a reçu un vote d'encouragement, environ la moitié (20/45) des personnes ayant encouragé le document de Sean Baxter, et 30/45 ayant encouragé le travail sur les Profils (avec 6 neutres) ».
Il semble donc que Sean Baxter soit invité à poursuivre ses efforts, et de nombreux membres du comité aimeraient le voir...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.


Quel est votre avis sur le sujet ?