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 !

20 % des unités de compilation (crates) Rust utilisent le mot-clé "Unsafe", qui offre aux développeurs une certaine flexibilité dans les cas où les garanties du compilateur sont trop restrictives

Le , par Anthony

45PARTAGES

4  0 
La fondation Rust rapporte que près de 20 % des crates Rust utilisent le mot-clé « unsafe », ce qui met en évidence un aspect critique de la gestion de la mémoire dans la programmation Rust. Alors que Rust est réputé pour ses dispositifs de sécurité robustes, les blocs de code « unsafe » offrent aux développeurs une certaine flexibilité dans les situations où les garanties du compilateur sont trop restrictives. Malgré ces blocs, Rust maintient des protections strictes pour minimiser les vulnérabilités. La fondation Rust continue de mettre l'accent sur la sécurité, en développant des outils et des initiatives pour soutenir l'utilisation sécurisée de « unsafe » dans la programmation Rust.

Rust est un langage de programmation polyvalent multi-paradigme qui met l'accent sur les performances, la sécurité des types et la concurrence. Il assure la sécurité de la mémoire, c'est-à-dire que toutes les références pointent vers une mémoire valide, sans ramasse-miettes. Afin d'assurer simultanément la sécurité de la mémoire et d'éviter les courses aux données, son « vérificateur d'emprunts » suit la durée de vie de toutes les références d'un programme pendant la compilation.


Un billet de blog de la Fondation Rust commence par rappeler aux lecteurs que les programmes Rust « ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution ». Mais le billet poursuit en explorant « Unsafe Rust in the wild » (utilisé pour un petit ensemble d'actions telles que le déréférencement d'un pointeur brut, la modification d'une variable statique mutable ou l'appel à des fonctions non sûres).

« À première vue, il peut sembler que Unsafe Rust compromette les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est accompagné de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées. »

La Fondation énumère dans son billet les mesures de protection disponibles, qui « rendent les exploits rares, mais pas impossibles ». Mais elle analyse également la quantité de code Rust qui utilise réellement le mot-clé unsafe.

Le contenu du billet de blog de la Fondation Rust est présenté ci-dessous :

Les programmes accèdent à la mémoire - ce concept est fondamental en informatique. Selon le langage de programmation utilisé pour écrire le code, il existe différentes manières de gérer l'allocation et l'utilisation de cette mémoire. Chaque approche requiert prudence et précaution.

Un accès involontaire et hors de portée aux zones de mémoire d'un programme peut exposer des données sensibles ou servir de point d'entrée pour l'exploitation, ce qui représente un risque important et peut contribuer à des attaques de type « zero-day ». En résumé, qu'un programmeur gère et alloue la mémoire manuellement ou qu'il compte sur le langage et le compilateur pour le faire à sa place, des pratiques robustes de gestion de la mémoire sont une nécessité.

Les problèmes de sécurité de la mémoire représentent une part importante des vulnérabilités des logiciels. Les acteurs malveillants en sont bien conscients et utilisent un ensemble évolutif de tactiques pour exploiter le code non sécurisé en mémoire dans certaines des attaques logicielles les plus reconnaissables et les plus dommageables de ces dernières années, telles que Heartbleed.

Compte tenu du nombre d'exploits logiciels nuisibles qui hantent notre industrie et de l'importance des enjeux, les fondations de logiciels, les consortiums technologiques et les gouvernements du monde entier prennent conscience de la situation et plaident en faveur de l'amélioration des pratiques et des outils de programmation.

La puissance et la promesse de Rust

Le langage de programmation Rust est souvent cité par les défenseurs de la sécurité de la mémoire comme l'un des langages de programmation les plus sûrs sur le marché aujourd'hui. Langage à mémoire sécurisée par défaut grâce à un concept appelé ownership, Rust fournit des règles et des garanties pour la gestion de la mémoire et considère la sécurité comme un concept de premier ordre.

Les programmes utilisant Rust ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution. Les développeurs Rust et les utilisateurs d'applications écrites en Rust ont ainsi la certitude que les vulnérabilités de la mémoire ne doivent pas être un sujet de préoccupation.

Safe Rust et « Unsafe Rust »

Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe.

Bien que l'utilisation de Unsafe Rust puisse théoriquement produire des vulnérabilités similaires à celles des langages non sûrs pour la mémoire, il existe quatre mesures de protection principales pour réduire ces risques à près de zéro :

  1. L'utilisation du mot-clé unsafe en Rust est un acte explicite, exigeant du développeur qu'il choisisse de le faire. Cela signifie que vous ne pourrez jamais entrer dans un contexte unsafe au sein de votre code Rust sans faire l'effort conscient de le faire ; d'autres langages peuvent vous permettre d'appeler directement du code unsafe ou non géré.
  2. Le code unsafe doit être isolé dans ses propres blocs de code. Si un problème survient lors de l'utilisation de Unsafe Rust, le code à l'origine du problème est clairement identifié.
  3. Il y a un nombre limité de façons d'utiliser unsafe et tout le code safe Rust continue à avoir ses contrôles de sécurité normaux même à l'intérieur d'un bloc unsafe.
  4. Le système de types de Rust fournit toujours des contraintes de sécurité pour les types sûrs de Rust, même à l'intérieur d'un bloc unsafe.

Ces mesures supplémentaires renforçant Unsafe Rust rendent les exploits rares, mais pas impossibles. Pour déterminer le risque posé par Unsafe Rust, il faut examiner combien de code Rust utilise le mot-clé unsafe.

Unsafe Rust en milieu naturel

La façon canonique de distribuer du code Rust est par le biais d'un paquetage appelé crate. En mai 2024, il existe environ 145 000 crates, dont environ 127 000 contiennent du code significatif. Sur ces 127 000 crates, 24 362 font usage du mot-clé unsafe, soit 19,11 % de tous les crates. Et 34,35 % font un appel direct à une fonction dans une autre crate qui utilise le mot-clé unsafe. Près de 20 % de tous les crates ont au moins une instance du mot-clé unsafe, ce qui n'est pas négligeable.

La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++. En fait, la crate qui utilise le plus le mot-clé unsafe est la crate Windows, qui permet aux développeurs Rust de faire appel à diverses API Windows. Cela ne signifie pas que le code de ces blocs Unsafe Rust est exploitable en soi (la majorité ou la totalité de ce code ne l'est probablement pas), mais qu'une attention particulière doit être portée à l'utilisation de Unsafe Rust afin d'éviter les vulnérabilités potentielles.

À première vue, il peut sembler que Unsafe Rust réduit les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est assorti de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées.

Sûreté et sécurité : une responsabilité partagée

Comme cela a été dit, Rust est à la hauteur de sa réputation d'outil excellent et transformateur pour une programmation sûre et sécurisée, même dans un contexte Unsafe. Mais cette réputation nécessite des ressources, une collaboration et un examen constant pour être maintenue correctement. Par exemple, le projet Rust continue de développer des outils comme Miri pour permettre la vérification du code Rust non sécurisé. La Rust Foundation s'est engagée dans ce travail par le biais de son initiative de sécurité : un programme visant à soutenir et à faire progresser l'état de la sécurité au sein de l'écosystème et de la communauté du langage de programmation Rust. Dans le cadre de l'initiative de sécurité, l'équipe technologique de la Fondation Rust a développé de nouveaux outils tels que Painter, TypoMania et Sandpit pour détecter les vulnérabilités dans le code Rust, donnant aux utilisateurs un aperçu des vulnérabilités avant qu'elles ne se produisent et permettant une réponse rapide en cas d'exploitation.

La sûreté est une responsabilité partagée - ce concept est fondamental pour des communautés saines. Entre les développeurs qui utilisent Unsafe Rust, les groupes qui préconisent l'utilisation d'outils d'amélioration de la sécurité comme Rust, et les responsables du langage comme la Fondation Rust, nous avons tous un rôle à jouer dans les pratiques de programmation sécurisée. La collaboration et l'attention constante portée à la sécurité permettront au langage de rester aussi résistant que possible aux vulnérabilités à l'avenir.

Source : "Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust" (Fondation Rust)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Comment Rust améliore la sécurité de son écosystème : la Rust Foundation publie un rapport sur ce que leur initiative de sécurité a accompli au cours des six derniers mois de 2023

Consumer Reports publie un rapport détaillé encourageant l'adoption généralisée de langages sûrs pour la mémoire tels que Rust, et sensibilise sur les risques liés à la sécurité de la mémoire

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

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/11/2024 à 22:26
Amazon Web Services va, dans un effort conjoint avec la Fondation Rust, payer des développeurs pour vérifier 7500 fonctions non sécurisées de la bibliothèque Rust. C’est ce qui ressort d’une récente annonce qui ravive le débat sur la question de savoir si le Rust, initialement présenté comme un meilleur gage de sécurité pour les logiciels que C et C++, est en réalité plus sécurisé.
Ça ne ravive rien du tout. Le Rust n'a jamais prétendu empêcher tous les problèmes dans toutes les situations. Tous les gens un minimum renseignés savent que la bibliothèque standard contient des blocks unsafe (code non garanti par le compilateur) et c'est parfaitement attendu : elle doit fournir des abstraction sures aux appels systèmes fondamentalement unsafe. Ça reste toujours mieux que les lib standards de C et C++ qui n'ont pas de notion des sécurité intégrées au langage et qui laissent volontairement la possibilité d'utiliser certaines de leur abstractions de manière non sécurisée sans avertissement.

Que l'on essaye de vérifier formellement le code unsafe de Rust, reste quand même un plus pour pour améliorer encore la confiance que l'on peut lui accorder. Par contre, ce qui m'intrigue dans la démarche c'est qu'un code vérifié ne le reste que tant qu'il n'est pas modifié, je serais curieux de voir comment ils prévoient de gérer ça vu que la bibliothèque standard évolue en continu.
7  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 04/12/2024 à 22:19
Citation Envoyé par d_d_v Voir le message
Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois.
La plupart des gens que vous appelez fanatiques pro-Rust ne prennent la peine de défendre le Rust que parce des gens (que l'ont pourrait tout autant qualifier de "fanatiques du C++") crachent dessus, généralement sans trop savoir de quoi il parlent. Je ne parle normalement pas de Rust dans les news qui ne parlent que de C++ si ce n'est pour rectifier quelqu'un qui dirait des erreur sur Rust.

Citation Envoyé par d_d_v Voir le message
A chaque sortie ou mise en avant d'un "nouveau" langage, on a droit toujours aux mêmes promesses. J'ai vu la même chose avec DotNet, Java (qui a aussi son mode unsafe si je me souviens bien), pour d'autres promesses mais aussi celle de la gestion mémoire.
Le unsafe en DotNet et Java n'est pas forcément comparable car ces langage n'ont pas la prétention d'être des langages systèmes. Je n'ai jamais eu besoin de me pencher sur le unsafe en C#, mais au moins, en ce qui concerne en Java, la notion de unsafe ne fait pas officiellement partie du langage. La plupart des JRE embarquent bien une classe Unsafe, mais elle ne fait pas partie de la bibliothèque standard et elle n'est pas officiellement supportée. En général quand on veut faire proprement en Java ce que l'on ferait avec du unsafe en Rust, on passe par des bibliothèque natives en C/C++/ou maintenant Rust.

Citation Envoyé par d_d_v Voir le message
La première sécurité, c'est d'embaucher des gens compétents, c'est pareil dans tous les domaines. Vous n'avez pas besoin de fournir un couteau avec une lame en plastique à un pâtissier de peur qu'il se blesse
Ces comparaisons sont simplistes notamment car elles impliquent que les problèmes de sécurité ont un impact immédiatement visible chez le producteur. Mais ce qui fait la particularité des failles de sécurité, c'est qu'elle ne sont pas forcément évidents à éviter et à identifier et elles auront un impact bien plus tard sur l'utilisateur du logiciel.
Pour reprendre la cas du pâtissier : il a bien fait son boulot s'il livre un bon gâteau. Il n'a pas a craindre que parce qu'il n'a pas tenu le couteau parfaitement à la verticale quand il a découpé les fraises, le gâteau devienne toxique quand on le mange la tête en bas un Mardi de pleine lune.

S'il suffisait d'avoir à disposition des développeurs chevronnés pour éviter les problèmes on aurait pas tant de failles, y compris dans les logiciels les plus surveillés au monde comme les navigateurs, OS, base de données ...

Citation Envoyé par remi_inconnu Voir le message
Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité... Java, on connait l'histoire depuis.
Java ne résout clairement pas tous les problèmes possible (Rust non plus d'ailleurs), mais c’était clairement une amélioration comparé au C et C++ au niveau de la sécurité, même si (contrairement au Rust) il implique des concessions sur l'accès au bas niveau et la maitrise des performances.

Citation Envoyé par remi_inconnu Voir le message
Ne jamais oublier que la première cause de défaillance de sécurité, se situe toujours entre la chaise et le clavier, croire qu'avec un langage, on va tout faire disparaître comme par magie, me fait beaucoup rire, surtout quand c'est des personnes gouvernantes qui disent cela en interview, ces mêmes personnes qui n'ont jamais écrit aucune ligne de code de leur vie.
On peut même aller au delà : le programmeur est la seule et unique cause des problèmes de sécurité. Le souci, c'est que quand on a dit ça, on a rien dit parce que malgré l'IA générative(qui est elle aussi faillible), on ne sait toujours pas faire de programmes un minimum complexe sans programmeurs.
Donc si on veut améliorer la sécurité, il faut améliorer le programmeur, et comme malgré toutes les formations et l'expérience accumulée, ça restera toujours un humain faillible, un compilateur qui permettent d’éviter les pratiques de codage problématiques, c'est un gros avantage. Et comme Rust ne résout pas directement les problèmes (comme Java ou C#) ou les ignore (comme parfois en C et C++), mais les explique, c'est également un très bon moyen de formation.
6  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/11/2024 à 14:39
Citation Envoyé par OuftiBoy Voir le message
Mais comme tout langage, il se doit de posséder une librairie standard. Et comme beaucoup de langages, il s'appuie sur des librairies écritent en 'C'.
Normalement, petit à petit, je pense que l'équipe de Rust tentera de s'affranchir de ces librairies, et c'est un travail énorme qui prendra encore quelques temps.
La bibliothèque standard n'utilise aucune librairie écrite en C en mode core (sans accès à l'OS) et seulement la libc en mode std(avec accès à l'OS).
L'utilisation de la libc n'est pas faite pour économiser du travail : c'est juste parce que la plupart des OS n'ont pas de façon directe et stable de s'interfacer avec eux. La lib C est juste utilisée comme interface stable avec l'OS.

Citation Envoyé par OuftiBoy Voir le message
Mais, la question qui pour moi est la plus importante, c'est de savoir si l'utilisation de ces 20% de bloc "unsafe" sont utilisés pour fournir "rapidement" une librairie standard relativement complète, OU s'il est impossible de se passer de ces blocs "unsafe" pour avoir les fonctionnalités contenues dans ces 20%.
En Rust on utilise clairement pas des bloc unsafe par plaisir, s'ils sont utilisés dans la bibliothèque standard, c'est certainement qu'ils sont nécessaire, soit pour accéder a des fonctionnalités bas niveau que les règles de Rust ne peuvent garantir, soit pour des raisons de performance. Et en soi ça n'a rien de problématique pour l'utilisateur de la bibliothèque vu que ce code unsafe est encapsulé dans des abstraction qui elles sont safe.
Le but du projet est de vérifier que ces blocs de code, bien que marqués unsafe, sont corrects et que l'encapsulation est bien réalisée

Citation Envoyé par Freem Voir le message
Ce qui m'amuse toujours énormément avec le bruit autour de Rust, c'est qu'on dirait que tous les bugs du monde sont des bugs de corruption mémoire... mais c'est loin d'être le cas.
Par acquis de conscience je viens de regarder les dernières vulnérabilités reportées sur glibc (pour rester dans le domaine de la lib standard) : quasiment toutes étaient dues à des problèmes de mémoire. Donc, même si Rust ne garantira jamais l'absence totale de bug, c'est clairement un moyen très efficace pour en diminuer la quantité, surtout les plus dangereux pour la sécurité.

Citation Envoyé par Freem Voir le message
Si la bibliothèque standard de rust évolue encore tant, c'est que le langage est loin d'être mûr, et par conséquent, plein de bugs, et donc, pas safe. Au moins, pour le C et le C++, on dispose de décennies d'expérience
Si la bibliothèque standard évolue c'est que le langage évolue, ce qui est aussi le cas du C++. Le Rust aura bientôt 10 ans, et commence a avoir une utilisation assez conséquente pour échapper au procès en immaturité. Les retour sur l'utilisation du Rust montre clairement une amélioration de la sécurité et pas une dégradation.

Citation Envoyé par Freem Voir le message
les fonctions dangereuses sont bien identifiées, de nombreux outils (gratuits, donc pas de raison de pas les utiliser, mais malheureusement les systèmes de CI/CD déployés sur `git[a-z]{3}` les intègrent rarement... d'ailleurs ils vérifient jamais que chaque commit passe les tests, juste le dernier de la PR... c'est hors sujet.) aident a en éviter l'usage.Ces outils existent uniquement grâce à l'expérience accumulée par les utilisateurs de ces langages.Ces fonctions ne peuvent pas être supprimées (du standard), parce que l'historique, c'est important, quand on travaille sur un projet sérieux et pas du code jetable.
Sauf que l'efficacité des outils de vérification du C sont limitées, justement entre autre parce que le code dangereux nécessaire n'est pas correctement isolé du code sûr. Une grosse partie de la sécurité de Rust ressemble a ce que fait un analyseur statique de code C, mais le langage Rust a été conçu pour rendre cette vérification bien plus efficace.

Le C a certes développé des outils suite aux retours d'expérience, mais il ne faut pas croire que Rust serait reparti de zéro en ignorant l'état de l'art sur les autres langages. D'ailleurs, le nom de la toute première conférence qui a présenté Rust était clair là dessus : "Technology from the past come to save the future from itself".
Rust a complètement pris en compte l'expérience accumulée par d'autre langages (notamment le C et le C++). Et justement, le fait qu'il n'ait pas à gérer plusieurs dizaines d'années l'historique à permis de corriger à la racine beaucoup de problèmes qu'on peut juste essayer de mitiger en C et C++.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/05/2024 à 15:09
Oui le pirate visera toujours le maillon le plus faible, mais la sécurité ne fonctionne clairement pas en mode tout ou rien. En réduisant la quantité de code à risque, on diminue le risque de laisser une erreur exploitable.

Bien sur que Rust ne pourra jamais tout remplacer, et certainement pas du jour au lendemain. D'ailleurs même un code écrit 100% en Rust, sans aucun bloc unsafe ni composants externes, ne garantit pas une absence de failles de sécurité. Cependant, plus Rust permettra de diminuer la surface d'attaque, plus on gagnera en sécurité.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/05/2024 à 6:45
C'est différent de C++ dans le sens où la quantité de code à risque dont il faut particulièrement surveiller la validité de la mémoire est réduite à de petites sections clairement identifiées. En Rust, on ne peut pas introduire un risque d'insécurité mémoire sans s'en rendre compte.

Les problèmes de sécurité mémoire de C++ ne sont malheureusement pas limités aux constructeurs et même si c'était le cas, ça resterait une quantité de code exposée plus élevée que ce qu'il est normalement nécessaire de mettre en unsafe.
2  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 27/11/2024 à 13:45
Citation Envoyé par Freem Voir le message
Personnellement, je ne comprendrais pas l'adoption d'un outil si jeune et qui ne cesse de muter pour réaliser un projet qui serait censé être utilisé pour plus de 10 ans. Non, il ne sera plus maintenu super activement quelques années plus tard, s'il juste marche et n'est pas un projet de type "frontal", faut pas rêver.
Rust était certes un projet de recherche de Mozilla, mais a depuis quelques années des soutiens de poids:
https://foundation.rust-lang.org/members/
Je parie plutôt sur une installation progressive et ferme du langage.

Citation Envoyé par Freem Voir le message
Je suis plutôt un détracteur de rust en général, parce que le battage marketing a souvent un effet contraire sur moi
De quel battage marketing parle-t-on? Le langage est gratuit, et tout ce qui tourne autour. Le langage n'appartient pas à une grande marque. Et pour le coup, il n'a certainement pas été créé par une équipe de marketeurs.
3  1 
Avatar de remi_inconnu
Membre du Club https://www.developpez.com
Le 04/12/2024 à 21:31
Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité... Java, on connait l'histoire depuis.
Rust ne m'a pas l'air fini et n'est pas évident à prendre en main, et quand on a baigné dans un univers orienté objet, il ne donne pas vraiment envie de devoir s'en passer.
A notre époque on est noyé par des nouveaux langages, tous plus merveilleux que les précédents, et souvent bien éphémère, je ne dis pas que pour Rust sera pareil, mais avant de miser tout sur ce langage, il faut bien réfléchir aux conséquences, et peut être il ne sera qu'une mode passagère, comme beaucoup d'autre avant lui et après lui.
Ne jamais oublier que la première cause de défaillance de sécurité, se situe toujours entre la chaise et le clavier, croire qu'avec un langage, on va tout faire disparaître comme par magie, me fait beaucoup rire, surtout quand c'est des personnes gouvernantes qui disent cela en interview, ces mêmes personnes qui n'ont jamais écrit aucune ligne de code de leur vie.
5  3 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/05/2024 à 14:33
Citation Envoyé par Anthony Voir le message
La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++.
C'est dommage qu'il n'y ait pas de chiffre précis là dessus, car pour le coup ça fausse complètement la perception des autres chiffres.
C'est difficile de reprocher a Rust de ne pas assurer la sécurité du code écrit dans d'autre langages.
2  1 
Avatar de prisme60
Membre régulier https://www.developpez.com
Le 26/11/2024 à 14:57
Il n'y a pas photo. La sécurité du code Rust dépasse largement ce que l'on trouve en C et C++. Comme toute chose, il y a des marges d'amélioration, Rust reste un langage jeune, et il ne possède pas encore d'historique lourd à porter.

Le C est trop laxiste sur les appels de fonctions, gestion totalement manuelle des allocations dynamique sur le tas (malloc/free).

Le C++ a comblé quelques manques avec les différentes évolutions (regex, jthread, lambda, async/future, ranges/views), et au passage à rajouter une complexité supplémentaire (opérateur move, démultiplication des constructeurs, constraints/concepts, modules).
2  1 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 04/12/2024 à 14:45
Citation Envoyé par d_d_v Voir le message
Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois.
Je pensais que cette discussion concernait Rust. Serions-nous par mégarde intervenus fanatiquement dans une discussion concernant C++26?

Citation Envoyé par d_d_v Voir le message
Avec c++26, les contrats logiciels vont (enfin) arriver, c'est ça la vraie sécurité: pouvoir assurer les préconditions/postconditions de chaque fonction, c'est à dire, une partie de son contrat.
Je suis preneur de références à ce sujet. Quelles fonctionnalités de c++26, plus précisément?

À vrai dire, mais on ne parle sans doute pas de la même chose, j'utilise beaucoup les conditionnements de type en Rust (s'assurer qu'un type implémente effectivement un certain nombre de traits et donc de fonctionnalités) pour contrôler l'utilisation de mes fonctions ou de mes librairies.
1  0