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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Google accorde une subvention d’1 million de $ à la Fondation Rust


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 784
    Points : 50 393
    Points
    50 393
    Par défaut Google accorde une subvention d’1 million de $ à la Fondation Rust
    Google accorde une subvention d’1 million de $ à la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++
    Et faciliter la transition à Rust jugé supérieur pour sécuriser les logiciels

    Google accorde une subvention d’un million de dollars à la Fondation Rust pour soutenir les efforts d’interopérabilité avec le langage C++. En toile de fond, le géant technologique cherche à faciliter la transition à Rust que de plus en plus d’observateurs jugent supérieur à C et à C++ pour la sécurisation des logiciels. La tendance dans l’industrie technologique est telle que même Linus Torvalds reconnaît que Rust, qui a été adopté comme deuxième langage pour le développement du noyau Linux, est digne d’intérêt d’un point de vue technique.


    « 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.

    « 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.

    C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on est d’avis que « 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. »

    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 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, les adoptions du langage Rust visent à mettre à profit ces atouts du langage sur le C et le C++.


    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)); 
    }

    Source : Google

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juillet 2012
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juillet 2012
    Messages : 18
    Points : 83
    Points
    83
    Par défaut
    Dans mon entreprise, je me bas pour qu'on mette en place le Rust, que j'utilise sur mes projets persos.
    Le seul frein, c'est qu'en général on part d'un existant (du bon vieux code legacy C++ comme on l'aime, miamm!), et que tout refaire prendrait trop de temps. Faire des mixes de langages, c'est assez déconseillé, la compilation, le debug, tout devient plus compliqué.

    Dans le cadre du Web, on peut aussi utiliser un Framework Rust qui fait du WebAssembly. Je pense en ce moment à Leptos qui se démarque des autres Frameworks (Yew, Sycamore, Dioxus). Le problème, c'est que c'est en pleine évolution, et il est difficile de trouver un framework pérenne qui existera encore dans 10 ans. Les technologies du Web sont très versatiles. Il suffit de voir React, AngularJS, ... où les versions se suivent avec des ruptures de compatibilité ou tout simplement la technologie est devenue désuète / obsolète (Par exemple : JQuery).

  3. #3
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    882
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 882
    Points : 2 011
    Points
    2 011
    Par défaut Il n'y a pas d'arguments de raison en faveur de C/C++
    Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
    Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.

    En fait c'est détourner la question que de dire, oui mais C++ peut-être sécurisé. C'est oublié que l'on a un outils (Rust) qui fait déjà tout (ou presque) sans avoir besoin d'autant de précautions. Après, évidemment, comme pour COBOL, ce n'est pas demain que l'on aura tout recodé en Rust et quand le code est en C++, il n'est pas vraiment possible de rajouter un bout de code en Rust (C'est un peu l'objet de cette subvention de Google). La base de code en C/C++ est immense (Sans doute bien plus grande que celle de COBOL au moins aujourd'hui), les développeurs C/C++ ont donc du travail pour au moins 50 ans.
    J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire. C'est cependant un code très restreint en volume. Et même parfois ce n'est pas assez bas niveau, on doit passer en assembleur. A cette exception près, le C devrait être remplacer par le Rust. D'ailleurs, le choix du C au lieu du C++, à l'exception du très bas niveau, est fait pour des questions de performances, car en C++ on peut trop facilement utiliser des raccourcis qui ne sont pas optimisé en performances (Rapides mais pas très rapides), je pense entre autre aux smart-pointer... Ceux qui connaissent comprendront les 3 points de suspensions, pour les autres disons que simplement ce sont justement les super-pouvoirs de C++ qui sont vanté comme sécurisés.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  4. #4
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 21
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par abriotde Voir le message
    Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.
    Merci d'avoir verbalisé ce constat qui m'a fait abandonner le C++ il y a une grosse décennie.

    Citation Envoyé par abriotde Voir le message
    J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire.
    Je ne sais pas si le C est irremplaçable.

    Il y a des projets d'OS bien avancés écrits en Rust https://www.redox-os.org/.

    Le unsafe est possible en Rust, mais il faut en avoir une véritable maîtrise: pour développeurs expérimentés en Rust.

    Enfin, ce n'est pas parce qu'un code est sécurisé qu'il est nécessairement moins rapide ou moins bas niveau. L'exemple suivant [Playground] montre le code généré suite à une compilation Release. L'utilisation de références mutables plutôt que des pointeurs induit un code machine simplifié, qui est similaire à ce qu'on pourrait obtenir avec le mot clef `restrict` du C (les références mutables interdisent le chevauchement en mémoire):


    Nom : CaptureOptiRust.PNG
Affichages : 393
Taille : 62,3 Ko

  5. #5
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 238
    Points : 42 582
    Points
    42 582
    Par défaut
    Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.

    Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.

    Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++, que Rust est censé pallier.

    Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation

  6. #6
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 21
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.
    Je ne vais pas vous faire un code complet... et surement pas sur le playground... Pour ce qui est de l'exemple, il est là pour illustrer ce que peut apporter la sémantique du mode safe en termes d'optimisation de code. Dans le cas présent, cela permet d'économiser des échanges avec la mémoire. Sans le mot-clé restrict en C ou certaines directives non standard en C++ et propres au compilateur, vous ne pouvez pas obtenir ce genre d'optimisation, qui est par ailleurs permis par le FORTRAN.

    Citation Envoyé par chrtophe Voir le message
    Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise
    En effet, mais un développeur inexpérimenté doit-il faire du code critique dans des développements systèmes? Car c'est un peu ça l'intérêt du unsafe en Rust. En dehors de fractions de codes critiques devant être particulièrement optimisés, je ne vois pas l'intérêt d'un usage de unsafe.

    Citation Envoyé par chrtophe Voir le message
    Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?
    Actuellement, la dépendance de Rust est liée au linkage. L'infrastructure de l'OS d'accueil est utilisé. Typiquement Microsoft C++ build tools pour windows. Des librairies compilées de la libc, sans doute, pour linux.
    L'OS Redox fournit une relibc implémentée en Rust https://github.com/redox-os/relibc.
    Cette dépendance venant au moment du linkage, elle est transparente au niveau du code en rust lors de l'utilisation de la libraire standard; au pire, on héritera de contraintes de l'OS.
    Bien entendu, il est possible d'appeler des fonctions provenant d'une librairie C en utilisant du unsafe. Ce cas d'usage de unsafe est bien documenté et ne pose aucun problème. Le vrai problème vient d'un usage de unsafe qui serait UB (undefined behavior). Et c'est la connaissance des cas UB qui nécessite une certaine expertise. Car il y en a beaucoup plus qu'en C.

  7. #7
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 21
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    qui ne contient qu'une signature de fonction.
    ???
    La signature de la fonction, c'est ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     fn adds(a: &mut i32, b: &mut i32)
    Ça, c'est le code de la fonction (j'ajoute b à a, puis j'ajoute b à a; comme ce sont des références mutables, rust interdit la situation où a et b partagent le même emplacement mémoire, ce qui rend inutile les échanges en mémoire par movl):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    { *a += *b; *a += *b; }
    Citation Envoyé par chrtophe Voir le message
    Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.
    En pratique, le compilateur Rust vous génèrera un message d'alerte si votre projet contient du code non publique (donc non utilisable dans un autre projet), qui n'est jamais utilisé. Cette fonctionnalité vient par défaut, et peut être désactivée pour certaines parties du code. Visiblement, la directive no_mangle désactive ce message d'alerte. J'espère avoir répondu à votre question non formulée...

  8. #8
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 238
    Points : 42 582
    Points
    42 582
    Par défaut
    J'ai pas utilisé le bon terme, je voulais dire prologue.

    Merci pour la réponse en tout cas.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation

  9. #9
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 21
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++
    Je n'avais pas noté cette petite subtilité psychologique dans votre question à la première lecture: le développeur inexpérimenté qui transgresse les règles pour faire le job vite fait mais salement fait.
    Vous avez différents outils de diagnostic à disposition: miri pour détecter à l'exécution des undefined behaviour ; des add-on à cargo pour faire une statistique des codes unsafe, etc.
    Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.

  10. #10
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 453
    Points : 6 026
    Points
    6 026
    Par défaut
    Citation Envoyé par fdecode Voir le message
    Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.
    Remarque : Depuis Rust 1.74.0, la manière idiomatique est de le faire dans le Cargo.toml :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    [lints.rust]
    unsafe_code = "forbid"

Discussions similaires

  1. Réponses: 0
    Dernier message: 14/11/2020, 14h16
  2. Le PDG de Google prédit une très bonne année pour Android
    Par Baptiste Wicht dans le forum Android
    Réponses: 11
    Dernier message: 29/04/2009, 21h02
  3. Réponses: 2
    Dernier message: 02/04/2007, 19h41
  4. [guitare] Accorder une 12 cordes
    Par GregPeck dans le forum Musique
    Réponses: 8
    Dernier message: 16/01/2007, 23h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo