IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le créateur de C++ appelle à l'aide de la communauté du langage pour le défendre contre de graves attaques
D'agences de cybersécurité qui militent pour un passage à des langages plus sécurisés comme le Rust

Le , par Patrick Ruiz

75PARTAGES

14  0 
Le créateur de C++ appelle à l'aide de la communauté du langage pour le défendre contre de graves attaques
D’agences de cybersécurité qui militent pour un passage à des langages plus sécurisés comme le Rust

Bjarne Stroustrup, créateur du langage C++, appelle la communauté C++ pour qu'elle défende ce langage de programmation. Ce dernier est sous le feu des critiques des agences de cybersécurité et des experts techniques ces dernières années en raison de ses lacunes en matière de sécurité de la mémoire. L’initiative du créateur du langage C++ se fait dans un contexte d’urgence étant donné l’appel du CISA à l’abandon du C++ d’ici à 2026.

« Il ne s'agit manifestement pas d'une note technique traditionnelle proposant un nouveau langage ou une nouvelle fonctionnalité de bibliothèque. Il s'agit d'un appel à une action urgente, en partie en réponse à des attaques graves et sans précédent contre le C++. Je pense que le WG21 doit faire quelque chose de significatif et être perçu comme tel. Profiles est un cadre qui peut le faire », déclare-t-il dans le cadre de la présentation de nouvelles lignes directrices pour la sécurité des ressources et des types.

« Comme je l'ai déjà dit, il s'agit également d'une opportunité car la sécurité des types et la sécurité des ressources (y compris la sécurité de la mémoire) ont été des objectifs clés du C++ depuis le tout début », ajoute-t-il.



Certains acteurs de la filière du développement de logiciels sont d’avis qu’il faut arrêter d’initier de nouveaux projets en C++ et passer au Rust

Mark Russinovich de Microsoft recommande le langage Rust plutôt que le C ou C++. Les raisons : la parité en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. C’est en droite ligne avec cet état de choses que l’éditeur de RisingWave a abandonné son projet de SGBD cloud natif initialement développé en C++ pour le réécrire en Rust.

« Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe », explique-t-il.



Linus Torvalds est d’avis que Rust est une solution d’avenir pour le noyau Linux mais certains intervenants pensent le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Néanmoins, certains intervenants comme le développeur Peter Anvin sont d’avis que C++ moderne est une meilleure alternative que Rust pour le développement du noyau Linux :

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir. »

Avec l’introduction des extensions Safe C++, le C++ se positionne pour rester pertinent et compétitif face aux nouveaux langages de programmation. Cette évolution devrait permettre au C++ de s’adapter et évoluer pour répondre aux besoins modernes de sécurité et de fiabilité des logiciels. Les extensions Safe C++ représentent une avancée majeure pour un langage qui continue de jouer un rôle crucial dans le monde de la programmation.

Source : Bjarne

Et vous ?

Partagez-vous les avis selon lesquels les extensions Safe C++ peuvent permettre au C++ de rivaliser avec les langages modernes comme Rust en termes de sécurité ? Pourquoi ou pourquoi pas ?
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
Vous avez lu gratuitement 2 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de kmedghaith
Membre confirmé https://www.developpez.com
Le 03/03/2025 à 14:37
A mon humble avis, et en tant qu'utilisateur de C++ depuis presque 20 ans, la meilleure façon de défendre le langage est de le faire évoluer en arrêtant de faire la sourde oreille à certaines demandes très raisonnables:
* Une nouvelle librairie standard, memory safe par défaut. De préférence commune à touts les compilateurs autant que possible, opensource et régulièrement mise à jour.
* Une syntaxe "C++2", sous ensemble du langage safe par défaut plus quelques additions pour le comfort. Pourquoi pas empreinter le borrow checker et les lifetimes (c'est fait dans circle)
* Un système de build et de dépendances standard et moderne

J'utilise pas mal Rust. Je comprends les gens qui veulent y passer: c'est moderne, simple et efficace. Ce n'est pas encore à parité avec le C++ concernant la programmation générique mais ça suffit pour 99% des développeurs.
Il est temps que le C++ apprenne de ses concurrents, juste comme ses concurrents ont appris du C++.
17  0 
Avatar de Jacti
Membre habitué https://www.developpez.com
Le 10/03/2025 à 12:26
Il fut un temps où, en plus de mon métier de concepteur/consultant, j'enseignais le C++ en entreprise à des développeurs qui connaissaient déjà d'autres langages (environ 1 cours de 5 jours/mois). Il s'agissait à l'époque de C++11. J'ai aussi audité, à l'aide de Logiscope des millions de lignes de C++ pour des applications militaires principalement (les fameux SIC et SIR). On pouvait déjà écrire du code très propre en C++ à condition d'être très discipliné et d'avoir fait une conception objet impeccable. Hélas, je me suis rendu compte que peu de développeurs comprenaient réellement et maîtrisaient la conception objet et la programmation en C++ "safe". Il me semble que les ajouts sont fait pour aider les développeurs et les guider dans des concepts qu'ils ne comprennent pas toujours jusqu'au fond des choses.
Peut-être que mon post est un peu provocateur mais c'est vraiment ce que je pense ayant pratiqué la conception objet dès le début en 1983 avec les articles de Grady Booch et le C++ dès 1993.
PS : j'ai pratiqué intensivement la métaprogrammation en C++ avec la généricité et il me semble que ce n'est qu'avec C++ qu'on arrive à faire des choses vraiment sophistiquées dans ce domaine. Rust ne lui arrive pas à la cheville.
5  0 
Avatar de freesket
Membre du Club https://www.developpez.com
Le 04/03/2025 à 9:58
Note this good summary by David Chisnall (ancien de chez Microsoft Research, chercheur à l'University de Cambridge et architecte système chez SCI Semiconductor) in a January 2024 FreeBSD mailing list post:
"Between modern C++ with static analysers and Rust, there was a small safety delta. The recommendation [to prefer Rust for new projects] was primarily based on a human- factors decision: it’s far easier to prevent people from committing code that doesn’t compile than it is to prevent them from committing code that raises static analysis warnings. If a project isn’t doing pre-merge static analysis, it’s basically impossible."

C++26 répondra à un certain nombre de points:
* La STL "hardened" par défaut (proposition rapidement adoptée car presque tous les fournisseurs de STL ont cette "option") => suppression des violations de type "bound safety".
* Le "initialisation safety"
* Les contrats (possibilité de vérifier les pré-requis et post-requis)
* Probablement la réflection statique
* Devrait apporter des profils (possiblement incomplets) pour vérifier les "type, bound, lifetime safety", inspirés de ce qu'il se fait avec les outils fournis avec clang ou cl. L'avantage c'est que ce sera directement à la compilation et non pas dans un outil séparé.
=> Conséquence, C++26 va rendre les méthodes "unsafe" (venant souvent du C) visibles (naked union, variant, enum C, NULL, pointeur de type array, for à l'ancienne, naked new/delete, malloc/free, cast douteux, les fonctions C unsafe...) et donc rendre le language plus propre et épuré pour ceux qui ne désactiverons pas la vérification à la compilation.
* Pour le petit plus (exemple not_null<T>, narrow_cast...) il faut voir du côté de la GSL (Guideline Support Library).
4  0