Le comité de normalisation de C++ a rejeté une proposition de créer un sous-ensemble sécurisé du langage. Les membres préfèrent se focaliser sur le framework Profiles poussé par le créateur de C++ Bjarne Stroustrup.
Régulièrement taclé pour son manque de sécurité, le langage C++ essaye de trouver un moyen de protéger l’accès mémoire et éviter d’être remplacé par des solutions plus sûres comme Rust. Plusieurs propositions ont été faites dont une par Sean Baxter, qui vise à la création d’un sous-ensemble de C++ plus sécurisé. Mais son initiative a été retoquée par le WG21 qui est le comité de normalisation du langage, rapporte The Register. Les membres ont préféré cibler leurs efforts sur le framework Profiles promu par Bjarne Stroustrup, le créateur de C++.
Face aux attaques répétées contre la faible sécurité du langage, le fondateur a proposé un ensemble de lignes directrices, des profils pour moderniser C+= comme l’interdiction e variables non initialisées, de plage, de fuites de ressources, de violation de type, d’invalidation, … Mais ce cadre a été accueilli avec scepticisme. Robin Rowe à l’origine de TrapC (une initiative pour répondre à la sécurité mémoire des langages C et C++) estime que Profiles n’est pas la solution miracle. « Si vous marquez votre code pour appliquer un Profile, certaines fonctionnalités du langage C/C++ cesseront de fonctionner », glisse-t-il. Petit hic également, ces orientations n’ont pas été intégrées dans la version 26 de C++, mais simplement dans un livre blanc.
Circle, Rust ou Carbon de Google
De son côté, Sean Baxter a proposé une solution où les développeurs de C++ pourrait bénéficier de la mémoire sécurisée de Rust sans être obligés d’en apprendre un autre. Au coeur de son projet, il y a le Safe C++, un sous-ensemble du langage pour lequel il a développé un compilateur nommé Circle. Ce dernier intègre plusieurs fonctionnalités comme la vérification des emprunts pour éviter les bugs d’utilisation de mémoire une fois libérée et l’analyse d’initialisation pour la sécurité des types. L’avantage de cette solution est qu’il ne touche que le code qui vise à être sécurisé, la partie non-sécurisée fonctionne toujours. Pas de problème d’interopérabilité donc.
La controverse autour de la sécurisation de C++ ouvre la porte à une autre solution avec le recours à un autre langage. Le premier prôné par plusieurs autorités américaines est Rust, mais il existe aussi le projet expérimental Carbon de Google. Dévoilé en 2022, il vise lui aussi à moderniser C++.