La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust
Jugés supérieurs pour sécuriser les espaces mémoire des logiciels
Le 2024-02-28 17:28:36, par Patrick Ruiz, Chroniqueur Actualités
Faut-il arrêter d’initier de nouveaux projets en C ou C++ et passer à Rust ? La question divise dans la communauté des développeurs dont certains recommandent le langage Rust plutôt que le C ou le C++. Les raisons : la parité du Rust 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++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec un rapport de la Maison Blanche sur la sécurisation de la mémoire qui invite les développeurs à abandonner C ou C++ pour passer à des langages comme le Rust jugés supérieurs pour sécuriser les espaces mémoire des logiciels. C’est une sortie qui fait suite à la prise de position du créateur du langage C++ selon laquelle : « la sécurisation des logiciels par le Rust n’est pas supérieure à celle offerte par le C++. »
« En tant que nation, nous avons la capacité - et la responsabilité - de réduire la surface d'attaque dans le cyberespace et d'empêcher des catégories entières de bogues de sécurité d'entrer dans l'écosystème numérique, mais cela signifie que nous devons nous attaquer au problème difficile de l'adoption de langages de programmation sans danger pour la mémoire », écrit l'Office of the National Cyber Director (ONCD) de la Maison Blanche qui cite le Rust parmi les langages à adopter.
Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire.
« Les langages de programmation tels que C et C++ sont des exemples de langages de programmation qui peuvent conduire à un code non sûr pour la mémoire et qui sont encore parmi les langages les plus utilisés aujourd'hui. Pour tenter d'atténuer les dangers du code à mémoire non sécurisée obtenu en C et C++, de nombreux fabricants de logiciels investissent dans des programmes de formation à l'intention de leurs développeurs.
Nombre de ces programmes de formation comprennent des tactiques conçues pour réduire la prévalence des vulnérabilités de sécurité de la mémoire produites par ces langages. En outre, il existe de nombreux programmes de formation organisés par des associations commerciales et industrielles. En outre, diverses organisations et universités proposent des formations et un certificat professionnel pour démontrer la connaissance des pratiques de codage sécurisé en C et en C++.
Bien que la formation puisse réduire le nombre de vulnérabilités qu'un codeur peut introduire, étant donné l'omniprésence des défauts de sécurité de la mémoire, il est presque inévitable que des vulnérabilités de sécurité de la mémoire se produisent encore. Même les développeurs les plus expérimentés introduisent des bogues desquels peuvent résulter des vulnérabilités importantes. La formation doit servir de transition pendant qu'une organisation met en œuvre des contrôles techniques plus robustes, tels que des langages à sécurité mémoire », soulignent les Five Eyes dans un appel à abandonner C ou C++ et à passer à 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 », indique l'éditeur RisingWave à propos de la réécriture de son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++.
« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre », déclare Amazon. En effet, 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 Mark Russinovich recommande le Rust plutôt que le C ou le C++.
« En 2021, nous avons annoncé que Google rejoignait la Rust Foundation. À l'époque, Rust était déjà largement utilisé dans Android et d'autres produits Google. Notre annonce soulignait notre engagement à améliorer les examens de sécurité du code Rust et son interopérabilité avec le code C++. Rust est l'un des outils les plus puissants dont nous disposons pour résoudre les problèmes de sécurité de la mémoire. Depuis cette annonce, les leaders de l'industrie et les agences gouvernementales se sont fait l'écho de notre sentiment.
Nous sommes ravis d'annoncer que Google a accordé une subvention d'un million de dollars à la Fondation Rust pour soutenir les efforts visant à améliorer la capacité du code Rust à interopérer avec les bases de code C++ existantes. Nous poursuivons également notre engagement envers la communauté open-source Rust en regroupant et en publiant des audits pour les crates Rust que nous utilisons dans les projets open-source de Google. Ces contributions, ainsi que nos précédentes contributions en matière d'interopérabilité, nous rendent enthousiastes quant à l'avenir de Rust », écrit Google dans le cadre de l’annonce de l’accord d’une subvention d’un million de dollars de la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++.
« Nous sommes ravis de soutenir ce travail par le biais de l'initiative Interop de la Fondation Rust et en collaboration avec le projet Rust afin de s'assurer que tous les ajouts effectués sont appropriés et répondent aux défis de l'adoption de Rust auxquels les projets utilisant C++ sont confrontés. L'amélioration de la sécurité de la mémoire dans l'industrie du logiciel est l'un des principaux défis technologiques de notre époque, et nous invitons la communauté et l'industrie à se joindre à nous pour travailler ensemble à la sécurisation de l'écosystème open source pour tous », ajoute le géant technologique.
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. De façon graduelle, Microsoft migre vers ce dernier au détriment d’autres langages que l’entreprise juge moins outillés pour la mise sur pied d’applications dites système. Motif : Rust offre de meilleures garanties en matière de sécurisation des accès mémoire des logiciels.
« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui. Nous devons utiliser de façon systématique des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants », déclare Neal Ziring, directeur technique de la cybersécurité de la NSA.
En effet, il y a une liste de griefs qui reviennent à l’encontre de langages de programmation comme le C et le 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.
Le créateur du C++ est d’avis que « La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »
Mark Russinovich de Microsoft a déclaré que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »
En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.
« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.
Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.
L’équipe de Google dont la publication est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.
Sources : Rapport Maison Blanche sur la sécurisation de la mémoire, Communiqué de presse de la Maison Blanche
Et vous ?
Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?
Voir aussi :
L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
« En tant que nation, nous avons la capacité - et la responsabilité - de réduire la surface d'attaque dans le cyberespace et d'empêcher des catégories entières de bogues de sécurité d'entrer dans l'écosystème numérique, mais cela signifie que nous devons nous attaquer au problème difficile de l'adoption de langages de programmation sans danger pour la mémoire », écrit l'Office of the National Cyber Director (ONCD) de la Maison Blanche qui cite le Rust parmi les langages à adopter.
Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire.
« Les langages de programmation tels que C et C++ sont des exemples de langages de programmation qui peuvent conduire à un code non sûr pour la mémoire et qui sont encore parmi les langages les plus utilisés aujourd'hui. Pour tenter d'atténuer les dangers du code à mémoire non sécurisée obtenu en C et C++, de nombreux fabricants de logiciels investissent dans des programmes de formation à l'intention de leurs développeurs.
Nombre de ces programmes de formation comprennent des tactiques conçues pour réduire la prévalence des vulnérabilités de sécurité de la mémoire produites par ces langages. En outre, il existe de nombreux programmes de formation organisés par des associations commerciales et industrielles. En outre, diverses organisations et universités proposent des formations et un certificat professionnel pour démontrer la connaissance des pratiques de codage sécurisé en C et en C++.
Bien que la formation puisse réduire le nombre de vulnérabilités qu'un codeur peut introduire, étant donné l'omniprésence des défauts de sécurité de la mémoire, il est presque inévitable que des vulnérabilités de sécurité de la mémoire se produisent encore. Même les développeurs les plus expérimentés introduisent des bogues desquels peuvent résulter des vulnérabilités importantes. La formation doit servir de transition pendant qu'une organisation met en œuvre des contrôles techniques plus robustes, tels que des langages à sécurité mémoire », soulignent les Five Eyes dans un appel à abandonner C ou C++ et à passer à 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 », indique l'éditeur RisingWave à propos de la réécriture de son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++.
« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre », déclare Amazon. En effet, 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 Mark Russinovich recommande le Rust plutôt que le C ou le C++.
« En 2021, nous avons annoncé que Google rejoignait la Rust Foundation. À l'époque, Rust était déjà largement utilisé dans Android et d'autres produits Google. Notre annonce soulignait notre engagement à améliorer les examens de sécurité du code Rust et son interopérabilité avec le code C++. Rust est l'un des outils les plus puissants dont nous disposons pour résoudre les problèmes de sécurité de la mémoire. Depuis cette annonce, les leaders de l'industrie et les agences gouvernementales se sont fait l'écho de notre sentiment.
Nous sommes ravis d'annoncer que Google a accordé une subvention d'un million de dollars à la Fondation Rust pour soutenir les efforts visant à améliorer la capacité du code Rust à interopérer avec les bases de code C++ existantes. Nous poursuivons également notre engagement envers la communauté open-source Rust en regroupant et en publiant des audits pour les crates Rust que nous utilisons dans les projets open-source de Google. Ces contributions, ainsi que nos précédentes contributions en matière d'interopérabilité, nous rendent enthousiastes quant à l'avenir de Rust », écrit Google dans le cadre de l’annonce de l’accord d’une subvention d’un million de dollars de la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++.
« Nous sommes ravis de soutenir ce travail par le biais de l'initiative Interop de la Fondation Rust et en collaboration avec le projet Rust afin de s'assurer que tous les ajouts effectués sont appropriés et répondent aux défis de l'adoption de Rust auxquels les projets utilisant C++ sont confrontés. L'amélioration de la sécurité de la mémoire dans l'industrie du logiciel est l'un des principaux défis technologiques de notre époque, et nous invitons la communauté et l'industrie à se joindre à nous pour travailler ensemble à la sécurisation de l'écosystème open source pour tous », ajoute le géant technologique.
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. De façon graduelle, Microsoft migre vers ce dernier au détriment d’autres langages que l’entreprise juge moins outillés pour la mise sur pied d’applications dites système. Motif : Rust offre de meilleures garanties en matière de sécurisation des accès mémoire des logiciels.
« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui. Nous devons utiliser de façon systématique des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants », déclare Neal Ziring, directeur technique de la cybersécurité de la NSA.
En effet, il y a une liste de griefs qui reviennent à l’encontre de langages de programmation comme le C et le 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.
Le créateur du C++ est d’avis que « La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »
Mark Russinovich de Microsoft a déclaré que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »
En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.
« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.
Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.
L’équipe de Google dont la publication est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.
Code Rust : |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | #include <type_traits> #include <utility> #include <assert.h> #include <stddef.h> enum NoRefs {}; enum HasMutRef {}; enum HasRefs {}; template <class T, typename Mode> class Own; template <class T> class MutRef; template <class T> class Ref; template <class T, typename... Args> inline Own<T, NoRefs> make(Args... args) { return Own<T, NoRefs>(std::forward<Args>(args)...); } template <class T> inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { return Own<T, NoRefs>(std::move(own)); } template <class T> inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { return Own<T, NoRefs>(std::move(own)); } template <class T> std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { T* t = own.t_; own.t_ = nullptr; return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); } template <class T> std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { T* t = own.t_; own.t_ = nullptr; return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); } // No refs exist. template <class T> class [[clang::trivial_abi]] Own<T, NoRefs> { public: template <typename... Args> Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} ~Own() { delete t_; } Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } private: friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} Own(Own<T, HasRefs>&& own) : t_(own.t_) {} T* t_; }; // A mut ref exists. template <class T> class [[clang::trivial_abi]] Own<T, HasMutRef> { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } private: friend class Own<T, NoRefs>; Own(T* t) : t_(t) {} ~Own() {} T* t_; }; // Non-mut refs exist. template <class T> class [[clang::trivial_abi]] Own<T, HasRefs> { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } Ref<T> ref() { return Ref<T>(t_, &count_); } private: friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); explicit Own(T* t) : t_(t) {} ~Own() { assert(count_ == 0u); } T* t_; uint32_t count_; }; template <class T> class MutRef { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } ~MutRef() = default; MutRef(MutRef&& other) : t_(other.t_) {} private: friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); MutRef(T* t) : t_(t) {} T* t_; }; template <class T> class Ref { public: T& operator*() const noexcept { return *t_; } T* operator->() const noexcept { return t_; } ~Ref() { --(*count_); } Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} private: friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } T* t_; uint32_t* count_; }; MutRef<int> Borrows(MutRef<int> i) { (*i)++; return i; } TEST(Borrow, HelloWorld) { // Can't do this. The HasMutRefs type is not destructible outside of // consume()in order to have compiler check it is re-owned, but it won't // compile. To pass the HasMutRefs to consume() it has to be destroyed both // inside and outside of consume(). This is true even if trivial_abi is // used and only one destructor would actually run. Own<int, NoRefs> i = make<int>(5); auto& hasmut = mut(std::move(i)); MutRef<int> ref = Borrows(std::move(hasmut.second)); Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref)); } |
Sources : Rapport Maison Blanche sur la sécurisation de la mémoire, Communiqué de presse de la Maison Blanche
Et vous ?
Voir aussi :
-
KsassPeukMembre confirméhttps://stackoverflow.com/questions/...c-c-i-i-vs-i-i
D'ailleurs le compilateur peut grogner aussi :Code : 1
2
3
4
5
6$ gcc -o out a.c -Wall a.c: In function ‘main’: a.c:3:17: warning: operation on ‘i’ may be undefined [-Wsequence-point] 3 | int j = i++ + ++i ; | ^~~
Qu'est ce qui n'est pas clair dans la définition de "undefined behavior" dans la norme ?le 29/02/2024 à 18:13 -
UtherExpert éminent séniorC'est pourtant un cas d'école bien connu de Undefined Behaviour : modifier la valeur d'une variable plus d'une fois dans une séquence. Le compilateur est libre de faire ce qu'il veut avec ce genre d'expression.le 29/02/2024 à 9:53
-
UtherExpert éminent séniorBien sur que personne de censé n'écrira ça, c'est juste un exemple assez connu de "Undefined Behaviour" qui a l'avantage de tenir en quelques caractères. Ce n'est clairement pas le cas le plus discret, pourtant commandantFred ne l'a pas correctement identifié, et ce n'est probablement pas parce qu'il est idiot ou mal formé. En fait je ne connais pas grand monde, qui connaisse les presque 200 cas qui entrainent des UB dans la spécification du C, à part peut-être certains développeurs de compilateurs. Et même quand on connait un UB, ça ne veut pas dire que l'on pourra l'identifier dans tous les cas pratiques dans du code réel. Tous les humains sont faillibles.
Même dans des gros logiciels critiques, très surveillés et maintenus par des experts, on a la majorité des failles critiques qui viennent de la sureté mémoire. Si la formation était une solution suffisante, le problème n'existerait plus depuis longtemps dans les logiciels où l'on porte de l'attention à la sécurité.
C'est assez comparable au code de la route en fait : les conducteurs bien formés ne devraient théoriquement pas causer d'accident. Et pourtant, malgré l'épreuve du permis de conduire, on a toujours des accidents de la route, car la pratique de la conduite, tout comme la pratique du codage, repose sur avant tout sur l'humain.
C'est pour cela que c'est important d'améliorer la sécurité des langages, tout comme on améliore la sécurité des voitures.
Et c'est très bien, mais si c'est vraiment le cas, je ne vois pas pourquoi ne pas considérer sérieusement les apports de Rust pour la sécurité. L'humilité, c'est aussi prendre en compte que l'humain restera toujours faillible, et qu'il est intéressant qu'il puisse se reposer sur des outils qui prévienne ses erreurs.
Pour reprendre la comparaison avec l'automobile : on peut être un bon conducteur, très prudent, et quand même mettre sa ceinture de sécurité.le 29/02/2024 à 13:10 -
UtherExpert éminent séniorC'était vrai aux débuts de C++, mais de nos jours il s'est trop complexifié et a divergé sur certains points. Même s'il embarque encore une bonne partie de l'héritage du C, ce n'est plus une simple surcouche depuis au moins 20 ans.
C'est malheureusement plus compliqué que ça. Il existe des technologies, tout à fait utilisables en C, qui permettent déjà de se protéger de ce que vous décrivez, comme la DEP (protection contre l’exécution des données) ou l'ASLR (positionnement aléatoire des adresses). C'est très bien, mais ça n’est que de la mitigation : les bugs sont toujours là et des attaquants assez malins arrivent encore à trouver des moyens pour les exploiter.
Rust n'utilise pas de Garbage Collector pour la gestion mémoire. Sur ce point il fonctionne exactement comme C ou C++, excepté qu'il impose au programmeur des règles à respecter sur la façon d'utiliser les références (l’équivalent des pointeurs), ce qui permet, dès la compilation de garantir que l'on ne peut jamais manipuler une données non valide.
Je vois pas trop le rapport avec WebAssembly ou LLVM. Le C n'est de toute façon pas près de disparaitre ou de perdre en performance. Si on a pas pu se débarrasser de COBOL alors que ça fait plus de 30 ans qu'on essaie, je pense que le C en a pour au moins encore autant, probablement plus
Sauf que les deux tiers des vulnérabilités critiques qu'on trouve dans tous les gros logiciels C++ viennent d'erreurs mémoire. Donc soit les incompétents sont partout, soit les meilleurs experts font aussi parfois des erreurs (probablement un mix des deux). Dans tous les cas, on a un gros problème à résoudre, connu depuis plus de 40 ans, et tous les moyens qui on un effet mesurable sont bon à prendre. S'il suffisait de désigner des coupables, on aurait tourné la page depuis longtemps.
Tout dépend de la définition que l'on a d'exceptionnel.
En un sens il est vrai que, techniquement, la manière de gérer la mémoire n'est pas exceptionnelle. Structurellement, on a une pile classique et un tas alloué dynamiquement, tout comme en C. On gère les ressources en RIIA comme en C++. Même les principes centraux en Rust que sont l'ownership et les lifetime n'ont pas été inventées par Rust. Ce sont des bonnes pratiques que l'on recommandais déjà en C et C++.
Mais le fait que le compilateur garantisse la stricte application de ces principes est exceptionnel, car pour le moment sans d’équivalent dans aucun autre langage (actuellement utilisable) de ma connaissance. Le fait de pouvoir à la fois empêcher totalement les vulnérabilités mémoires tout en conservant l'efficacité du système de gestion mémoire de C fait tout l’intérêt du Rust.
En effet Ada permet de traiter des problématiques de sécurité y compris certaines que Rust ne sait pas (encore) traiter, mais inversement il y a des problématique de sécurité que Rust traite mieux que Ada, qui est d'ailleurs en train d'ajouter un système de borrow checker, inspiré directement de Rust.
Les deux langages ont leur intérêt propre, Rust étant quand même plus orienté productivité et il reste plus proche du C que Ada, ne serait-ce qu'au niveau de la syntaxe.
Les dépassement de buffer ne sont qu'un seul type d'erreur de sureté mémoire. Rust prévient aussi les autre erreurs de sureté mémoire comme l'utilisation de mémoire déjà libérée, les doubles libérations, les accès à la mémoire non initialisée ou les accès concurrents à la même donnée mémoire.
Je connais pas le compte exact pour le cas particulier de Linux, mais dans quasiment tout les gros projets C et C++ qui ont fait le calcul, on arrive à environ 2/3 des vulnérabilités importantes liées à des erreur de sureté mémoire. Ça en laisse un bon tiers, mais ça reste un progrès très important.
Il n'y a pas forcément besoin de tout réécrire du jour au lendemain. C'est sur que réécrire de zéro une base de code complexe mais bien maitrisée n'est pas forcément une bonne idée. Rust n'a pas vocation à écraser systématiquement l’existant si on n'en ressent pas le besoin. Par contre pour les nouveaux projets et les cas on on a de toute façon besoin de faire une réécriture, il serait idiot de ne pas considérer ces avantages face aux langages qui n'offrent pas la même sécurité.
Je pense qu'il y a confusion entre le C et le C++, parce que le C est probablement le langage qui a le moins évolué ces 20 dernières années, et le peu qui a changé c'est surtout pour le rendre plus propre, pas plus complexe.
Alors autant je suis en partie d'accord sur le fait qu'on a beaucoup trop complexifié certaine choses, il faut pas non plus tomber dans le "c'était mieux avant". Il reste beaucoup de choses qui changent de manière tout à fait justifiées.le 28/02/2024 à 23:03 -
UtherExpert éminent séniorTon compilateur sort peut-être actuellement le résultat que tu attends, mais c'est une erreur de penser que c'est forcément le résultat qu'il devait te retourner. D'après le standard, le compilateur est libre de faire absolument ce qu'il veux de ce genre d'instruction. Le comportement de cette expression pourrait très bien changer en fonction de la portion du code dans laquelle elle se trouve, des paramètres d'optimisation, de la version du compilateur ou autre.
Comparer avec JavaScript n'a pas de sens vu que sa spécification est différente. Je ne connais bien la spec de JavaScript, mais il me semble que, comme en Java, l'évaluation des éléments d'une expressions est précisément défini. Je ne suis même pas sur que le concept de UB existe en JavaScript.le 29/02/2024 à 15:52 -
UtherExpert éminent sénior
C'est la tragédie des codes reposant sur des UD, on peut avoir quelque chose qui marche, jusqu'au jour où ça ne marche plus, parce qu'on a changé de compilateur ou de réglage d'optimisation par exemple. Donc les tests c'est bien, mais malheureusement ça ne démontre pas l'absence de Undefined Behavior.
Notez que je n'ai pas parlé d'ésotérisme mais de comportement non déterminé (Undefined Behavior), c'est a dire des cas certes syntaxiquement valide mais que le programmeur se doit d'éviter dans un code normal. Dans ces cas là, la spécification du C laisse libre cour au compilateur de faire ce qu'il souhaite, y compris des comportements surprenant, car il s'agit de cas qui ne sont pas censé arriver. Il est tout à fait possible (et même probable dans ce cas particulier de UD) que votre compilateur se comporte de manière tout à fait déterministe, mais le standard ne l'y force absolument pas. Le compilateur a tout à fait le droit (et dans certains cas, ne s'en prive pas) de changer de comportement, en fonction des besoins d'optimisation le plus souvent.
Même si votre compilateur est consistant, rien ne garantit qu'il le restera et un autre compilateur peut réagir différemment.
Alors comme source bibliographique le standard C++ ça vous va ?
6.5 Expressions, §2
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
En effet je risque tellement de me faire blacklister de stackoverflow que je vous invite à regarder cette question où :
- la personne qui pose la question obtient des résultats variables avec son compilateur (chez moi Gcc et Visual Studio donnent des résultats à la fois différents entre eux et différent de la personne qui pose la question).
- une réponse à 600 votes lui explique que vu ce qu'est un UB ça peut arriver et qu'il n'y a pas de résultat à priori correct défini par le standard.
- d'autre réponses au alentours de 100 votes qui lui expliquent précisément ce qui dans la spécification cause ça.
Je ne vous demanderais pas de faire amande honorable ni profil bas, mais à défaut d’arrêter votre ton accusateur merci.
C'est certes l'ouvrage de référence dans l'apprentissage du C et il faisait également office de référence technique dans les années où il n'y avait pas encore de norme. Mais bon la première norme C remonte à il y a 35 ans, c'est clairement l'unique spécification technique reconnue par tous les compilateurs mainstream depuis bien longtemps.
Ce qui n'est pas faux, mais pas aussi précis que la norme qui introduit entre autre les "sequence points" qui permettent de préciser,le moment oui l'incrémentation se fait dans l'évaluation de l'expression ou la limitation du nombre de modifications d'une variable que j'ai cité plus haut.
Et c'est normal : "The C Programming Language" est un manuel, pas une spécification.
J'ose espérer pour tes collèges que tu n'as pas trop appliqué le principe de modifier plusieurs fois une variable dans une même expression, car en plus d'être un comportement indéterminé, c'est illisible.le 29/02/2024 à 19:16 -
PyramidevExpert éminentDe mon côté, pour C et C++, je m'appuie souvent sur en.cppreference.com. Les informations y sont bien classées et les pages insistent sur les différences entre les versions du C++ ou celles du C.
Pour le langage C, dans la page sur l'ordre d'évaluation, on peut lire :If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.
Code C : 1
2
3
4i = ++i + i++; // undefined behavior i = i++ + 1; // undefined behavior f(++i, ++i); // undefined behavior f(i = -1, i = -1); // undefined behavior
Dans N2176 (final draft du C17), à la page 55, on peut lire :If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.85)
The grouping of operators and operands is indicated by the syntax.86) Except as specified later, side effects and value computations of subexpressions are unsequenced.87)
85)This paragraph renders undefined statement expressions such as
Code C : 1
2i = ++i + 1; a[i++] = i;
Code C : 1
2i = i + 1; a[i] = i;
le 29/02/2024 à 19:51 -
KsassPeukMembre confirméBen non, pas "évidemment" du tout. Parce que le test exhaustif ça n'existe pas. Tout ce qu'un test garantit c'est qu'il n'y a pas de bug pour la trace d'exécution exécutée. Des traces d'exécutions il y en a un nombre pas du tout raisonnable dans un programme réaliste.
Ça tombe bien, la citation ne dit pas du tout qu'il ne faut pas tester. Elle dit juste que tester est insuffisant pour garantir l'absence de bugs. C'est même précisément pour ça qu'il a inventé une technique qui s'appelle le weakest precondition calculus (et que d'autres ont inventé pleins d'autres méthodes pour garantir l'absence de certains bugs, comme les procédures de typage par exemple).le 05/03/2024 à 16:22 -
dragonjoker59Expert éminent séniorTester c'est pour les faibles, il faut prouver son code...le 05/03/2024 à 16:04
-
IssamMembre confirméheuu 1 sec ,
c'est quoi le rapport entre la maison blanche et les languages de programmation ?le 28/02/2024 à 18:47