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

  1. #41
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 685
    Points
    685
    Par défaut
    Citation Envoyé par Uther Voir le message
    Si c'est vrai que comme le dit Stroustrup dans sa conférence, la sécurité du C++ a évolué tout au long de son histoire, ça a quand même été, pendant très longtemps, une préoccupation secondaire bien derrière la performance et la compatibilité. Il y avait certes de bonnes raisons de faire ce choix, mais, l'état actuel du C++ au niveau de la sécurité en est clairement la conséquence. Bjarne Stroustrup ne se penche sérieusement sur la sécurité du C++ que depuis qu'il y est poussé par l'arrivée des langages de bas niveau alternatifs et par les autorités de sureté.
    Je suis d'accord en partie. Mais il faut quand même préciser que la sécurité a toujours fait partie des préoccupations d'une partie du comité. Le principe même du RAII (cité dans l'article) date du début de la standardisation du C++. Par exemple auto_ptr a l'époque, mais également string, vector, etc.

    Mais quand on regarde les CVE/CWE (les vulnérabilités les plus communes), on voit que beaucoup sont liées à des buffer overflow, des memory leaks, etc. Des choses qui sont résolus depuis longtemps en C++ simplement en utilisant des string ou des vector, par exemple. On voit d'ailleurs dans l'article que la confusion C et C++ continue d'être faite.

    Et c'est le point où je voulais arriver : à mon sens, c'est pas juste (voire : pas principalement) un problème de langage et de comité, mais d'utilisateurs. On voit encore des débutants qui apprennent le C++ avec du code qui date d'il ya 20 ans. Et des pros faire pareil. Qui refuse d'apprendre les "nouvelles" pratiques (qui datent depuis plus de 20 ans !), les nouveaux designs, les nouveaux outils.

    Une grosse partie de l'intérêt de passer à un nouveau langage (Rust ou autre), c'est aussi de faire le tri entre les devs qui acceptent de se former, de réécrire leurs codes en suivant de nouvelles pratiques, en acceptant de supprimer l'ancien code non safe, etc. De plus, ce sont des projets qui se prêtent bien à la sécurisation, avec peu de code "unsafe" en Rust. (J'ai en tête par exemple la réécriture de binutils, qui n'est pas safe, mais utilise des char* partout. L'équivalent en C++ avec string sera safe sans aucun problème). Si un nouveau projet devait démarrer en C++, mais avec des devs qui sont formés, avec un code from scratch et un design orienté vers la sécurité, en mettant en place les outils, etc. est-ce qu'on n'aurait pas une sécurité équivalente à Rust ?

    Il faut reconnaître que la comparaison entre Rust et C++ est biaisée du fait que l'on compare souvent des nouveaux projets from scratch + équipe neuve qui veulent de la sécurité, versus du code legacy en C++ avec des équipes hétérogènes en compétences et motivations.

    Citation Envoyé par Uther Voir le message
    Il faudrait préciser ce que tu entends par là car Rust comme C++ sont relativement indépendant d'outils externes, pour le fonctionnement de base des langages au moins.
    Je pense qu'il parle du fait qu'une partie de la sécurité du C++ vient aussi des outils externes d'analyse statiques (clang sanitizer et autres). Si un langage "choisie" de détecter une vulnérabilité via le compilateur/sanitizer ou que cela soit fait via la sémantique du langage, on pourra obtenir le même niveau de sécurité sur cette vulnérabilité... à partir du moment où les devs choisissent d'activer cette détection ET de les corriger.

    Un langage qui intègre cette vérification dans sa sémantique sera plus sure, parce qu'elle laisse pas le choix aux devs. Mais au final, c'est pas forcément pertinent de comparer uniquement les langages, et pas les langages dans un écosystème complet. Et on est bien sur un problème de pratiques de devs. (Mais je dis pas non plus que toutes les vulnérabilités fixées par Rust ont un équivalent en C++ via les outils externes).

    Citation Envoyé par Uther Voir le message
    savoir ce qu'il permettra de faire même si ce n'est pas encore prêt et se qu'il ne permettra jamais de faire.
    C'est vrai par rapport a Rust et son manque d'écosystème actuel.

    Mais cela est également vrai par rapport au C++ et l'évolution future de ses outils de sécurité.

    On voit beaucoup d'évolutions du C++ et des outils qui sont directement inspirées d'autres langages, en particulier de Rust ces derniers temps. Choisir de nos jours de commencer un nouveau projet est aussi un pari sur les évolutions de ces 2 langages et de leurs écosystèmes. Mon pari est que justement, l'évolution future du C++ fera que l'on aura ("a" déjà, selon le type de projet) une sécurité équivalente à Rust.

    Dès maintenant, la majorité des bugs sur lesquels je bosse en C++ ne sont pas liés à de la sécurité mémoire. Et la réécriture en Rust (si on imaginait qu'il n'y a aucun coût de formation et de réécriture) des projets sur lesquels je bosse n'aurais pas ou peu d'impact sur la quantité de bugs a corriger ou la facilité d'ajouts de fonctionnalités. (Ou cela nécessiterait de passer par des "unsafe" en Rust)

  2. #42
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 490
    Points
    15 490
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Je suis d'accord en partie. Mais il faut quand même préciser que la sécurité a toujours fait partie des préoccupations d'une partie du comité. Le principe même du RAII (cité dans l'article) date du début de la standardisation du C++. Par exemple auto_ptr a l'époque, mais également string, vector, etc.
    Je dis bien que la sécurité fait partie des préoccupations, mais c'est loin d'être une priorité et quand il faut trancher entre la sécurité ou les performance et la compatibilité, la sécurité n'est généralement pas gagnante jusqu’à présent. Oui il y a eu des évolutions, mais peu ont été faites avec pour but de garantir la sécurité. Typiquement les vector et string ne sont pas du tout sécurisés contre les dépassement et l'invalidation des références. auto_ptr a plus été pensé pour éviter les fuites (et encore très partiellement) que pour prévenir des usages mémoire invalides.

    Citation Envoyé par mintho carmo Voir le message
    Mais quand on regarde les CVE/CWE (les vulnérabilités les plus communes), on voit que beaucoup sont liées à des buffer overflow, des memory leaks, etc. Des choses qui sont résolus depuis longtemps en C++ simplement en utilisant des string ou des vector, par exemple. On voit d'ailleurs dans l'article que la confusion C et C++ continue d'être faite.
    Les vector et string ne protègent pas des dépassement, du moins pas si on utilise les crochets qui sont pourtant la syntaxe la plus naturelle. De plus ils permettent d'obtenir des références à du contenu en mémoire qui peut devenir invalide.
    Les leaks mémoire sont pas des risques de vulnérabilité graves : le plus souvent le programme consomme juste trop de mémoire, au pire ça permet un DOS mais pas une execution de code arbitraire ou du vol de données.

    Citation Envoyé par mintho carmo Voir le message
    Et c'est le point où je voulais arriver : à mon sens, c'est pas juste (voire : pas principalement) un problème de langage et de comité, mais d'utilisateurs. On voit encore des débutants qui apprennent le C++ avec du code qui date d'il ya 20 ans. Et des pros faire pareil. Qui refuse d'apprendre les "nouvelles" pratiques (qui datent depuis plus de 20 ans !), les nouveaux designs, les nouveaux outils.
    Le problème ne vient pas que des utilisateurs. Le langage n'a pas fait grand chose pour pousser les utilisateurs à migrer vers les nouvelles pratiques, pour cela il aurait du déprécier ce qui est problématique. Malheureusement, le gros problème du C++, c'est qu'il est bâti sur un long héritage (qui remonte au C) qui n'a jamais pris en compte la sécurité comme un élément important. Il n'y a pas de sous-ensemble sûr clairement défini, qui ne serait pas incompatible avec 95% de l'existant.
    C'est difficile de reprocher aux gens de ne pas utiliser les bons outils quand ils ne sont pas facilement identifiables.

    Citation Envoyé par mintho carmo Voir le message
    Une grosse partie de l'intérêt de passer à un nouveau langage (Rust ou autre), c'est aussi de faire le tri entre les devs qui acceptent de se former, de réécrire leurs codes en suivant de nouvelles pratiques, en acceptant de supprimer l'ancien code non safe, etc.
    Ca va quand même au delà. En Rust, un programmeur qui viendrait du C++ avec de mauvaises pratiques et qui voudrait faire le même type de code n'y arrivera pas sans utiliser un bloc unsafe. Quelque part c'est une formation obligatoire à la sécurisation.
    Ca ne veut pas dire qu'il fera un code Rust de qualité, mais au moins on a la garantie qu'il ne fera une bonne partie des erreurs qui pourraient causer une faille de sécurité en C++.

    Citation Envoyé par mintho carmo Voir le message
    Je pense qu'il parle du fait qu'une partie de la sécurité du C++ vient aussi des outils externes d'analyse statiques (clang sanitizer et autres). Si un langage "choisie" de détecter une vulnérabilité via le compilateur/sanitizer ou que cela soit fait via la sémantique du langage, on pourra obtenir le même niveau de sécurité sur cette vulnérabilité... à partir du moment où les devs choisissent d'activer cette détection ET de les corriger.
    Dans le cas des sanitizers en effet ils méritent d'être pris en compte, sachant quand même que ce sont des outils dynamiques, certes très utiles, mais qui ne garantissent pas une couverture exhaustive des cas d'utilisation du code. Je pense que tout projet important se soucie un minimum de la sécurité et les utilise déjà, donc je doute que ça ait une importance énorme sur les chiffres de vulnérabilité des gros projets.

    Citation Envoyé par mintho carmo Voir le message
    On voit beaucoup d'évolutions du C++ et des outils qui sont directement inspirées d'autres langages, en particulier de Rust ces derniers temps. Choisir de nos jours de commencer un nouveau projet est aussi un pari sur les évolutions de ces 2 langages et de leurs écosystèmes. Mon pari est que justement, l'évolution future du C++ fera que l'on aura ("a" déjà, selon le type de projet) une sécurité équivalente à Rust.
    Je pense en effet que ça serait une bonne voie mais je vois mal comment faire un C++ aussi sécurisé que Rust sans déprécier tellement de choses que ça en deviendrait presque un dialecte séparé, et ça poserait énormément de défis avec l'historique de C++. Je ne suis pas certain que ça serait faisable facilement au sein du comité.
    Pour le coup les pistes d'évolution du type CppFront, Carbon ou Circle me semblent plus réalistes.

    Citation Envoyé par mintho carmo Voir le message
    C'est vrai par rapport a Rust et son manque d'écosystème actuel.
    Mais cela est également vrai par rapport au C++ et l'évolution future de ses outils de sécurité.
    Ce que je voulais dire c'est plutôt qu'il est intéressant d'analyser les capacités intrinsèques d'un langage pour savoir ce qu'il permet déjà de faire techniquement (même si certaines bibliothèques restent à coder), et ce qu'il ne permettra pas de faire à moins d'un évolution technique.

    Parier sur les évolutions d'un langage, c'est beaucoup plus spéculatif. C'est sympathique dans un forum de programmeurs, mais j’éviterais vraiment pour toute décision sérieuse.

  3. #43
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    25
    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 : 25
    Points : 90
    Points
    90
    Par défaut
    Citation Envoyé par Uther Voir le message
    Ca va quand même au delà. En Rust, un programmeur qui viendrait du C++ avec de mauvaises pratiques et qui voudrait faire le même type de code n'y arrivera pas sans utiliser un bloc unsafe. Quelque part c'est une formation obligatoire à la sécurisation.
    Ca ne veut pas dire qu'il fera un code Rust de qualité, mais au moins on a la garantie qu'il ne fera une bonne partie des erreurs qui pourraient causer une faille de sécurité en C++.
    Je vois néanmoins un problème dans l'utilisation des blocs unsafe pour quelqu'un venant du C/ C++ : il est indispensable de savoir ce qui est undefined behavior et ce qui ne l'est pas. Et cette connaissance demande une certaine maîtrise de Rust et peut-être des bases théoriques et une connaissance de la compilation. Par exemple, le fait que le compilateur puisse faire de l'optimisation de code en utilisant la connaissance sur le type de référence (non mutable `&` ou mutable `& mut`) fait qu'un code unsafe peut avoir un comportement différent en mode Debug ou en mode Release (optimisé) si on a eu la mauvaise idée de transformer une référence non mutable en référence mutable par un bloc unsafe.

  4. #44
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 490
    Points
    15 490
    Par défaut
    En effet, la contrepartie d'avoir du code safe garanti sans Memory leak est que le code "unsafe" nécessite plus de règles. Miri permet d'aider à détecter ce genre de problèmes.
    Heureusement dans la majorité des programmes, on a pas ou très peu de code unsafe a écrire. Si on se retrouve avec beaucoup trop de code unsafe dont on ne peut se passer, il vaut peut-être mieux regarder du coté de Zig qui à une sécurité mémoire intermédiaire entre le C et Rust, sans le concept de "unsafe".

  5. #45
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    25
    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 : 25
    Points : 90
    Points
    90
    Par défaut
    Citation Envoyé par Uther Voir le message
    [...] Miri permet d'aider à détecter ce genre de problèmes. Heureusement dans la majorité des programmes, on a pas ou très peu de code unsafe a écrire. Si on se retrouve avec beaucoup trop de code unsafe dont on ne peu se passer, il vaut peut-être mieux regarder du coté de Zig qui as une sécurité intermédiaire entre le C et le Rust.
    Miri est très utile et détecte beaucoup d'UB, mais pas toutes.
    Notamment, Miri ne fonctionne (fonctionnait?) pas en asynchrone, me semble-t-il. Donc il ne sera pas possible de tester du code asynchrone.

    Point dont je ne suis pas complètement certain: il me semble aussi que Miri fait le test d'UB à l'exécution comme le montrent les exemples en fin de message.
    Miri ne détectera donc pas toutes les UB.

    Avec Rust, je pense qu'il faut jouer le jeu et programmer avant tout en mode safe (même si on vient du C++).
    Le code unsafe ne devrait être envisagé que dans des cas bien documentés (dans l'API ou dans le Rustonomicon). Un cas typique est d'importer du code C.

    Ou alors, il vaut mieux aller demander l'information sur stackoverflow si le cas d'utilisation est douteux.
    Quand je dois utiliser une approche unsafe que je ne connais pas bien, c'est ce que je fais avec beaucoup de modestie désormais.

    Sincèrement, si un code est truffé d'unsafe comme vous dîtes, je pense qu'il faut en revoir la conception. C'est qu'on a utilisé une mauvaise approche.

    Les exemples:
    Voilà un code qui est UB et est repéré par miri [Playground]:
    Code : 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
    fn unsafe_fn(b: bool) {
        if b {
            unsafe {
                let y: *const i32;
                {
                    let x = 10;
                    y = &x;
                }
                println!("{}", *y);
           }
        }
    }
    
    fn main() {
        unsafe_fn(true);
        println!("it's running!");
    }
    
    ===================================
    
    Standard Error
    
       Compiling playground v0.0.1 (/playground)
        Finished dev [unoptimized + debuginfo] target(s) in 1.35s
         Running `/playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/playground`
    error: Undefined Behavior: out-of-bounds pointer use: alloc895 has been freed, so this pointer is dangling
      --> src/main.rs:9:28
    ...
    Et voilà un code presque identique, qui est UB, et n'est pas repéré par miri [Playground]:
    Code : 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
    fn unsafe_fn(b: bool) {
        if b {
            unsafe {
                let y: *const i32;
                {
                    let x = 10;
                    y = &x;
                }
                println!("{}", *y);
           }
        }
    }
    
    fn main() {
        unsafe_fn(false);
        println!("it's running!");
    }
    
    ===================================
    
    Standard Error
    
       Compiling playground v0.0.1 (/playground)
        Finished dev [unoptimized + debuginfo] target(s) in 0.48s
         Running `/playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/playground`
    
    Standard Output
    
    it's running!

  6. #46
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 490
    Points
    15 490
    Par défaut
    En effet Miri est un interpréteur qui va faire tourner le code en affichant une erreur si un UB intervient. C'est un fonctionnement assez similaire aux sanitizers en C++, et donc comme pour les sanitizers, la principale limitation est ça ne détectera que les cas qui sont effectivement déclenchés lors de l’exécution.

    Je suis aussi d'accord qu'en temps normal, on a pas besoin d'utiliser des blocs unsafe ou seulement en très petite quantité. Les cas ou on a besoin de beaucoup de blocs unsafe sont généralement très spécifiques. Je sais que, par exemple, le langage ROC a migré sa bibliothèque standard de Rust vers Zig pour cette raison, ce qui peut paraitre compréhensible vu que le principe de base d'une bibliothèque standard est d'offrir une interface avec l'OS dont le fonctionnement n'est habituellement pas "safe". Ca n’empêche pas que certaines bibliothèques standard ont été faites en Rust comme relibc ou celle du langage Rust lui même.

  7. #47
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 685
    Points
    685
    Par défaut
    Citation Envoyé par Uther Voir le message
    Je dis bien que la sécurité fait partie des préoccupations, mais c'est loin d'être une priorité et quand il faut trancher entre la sécurité ou les performance et la compatibilité, la sécurité n'est généralement pas gagnante jusqu’à présent.
    Oui. J'aurais du préciser que même si c'est une préoccupation de certains du comité depuis le début, c'est clairement pas la priorité numéro 1 du comité pendant longtemps et encore moins celle des utilisateurs. On voit encore beaucoup de débutants (ou moins débutant) qui viennent au C++ "pour les performances" (à tort, le plus souvent).

    Citation Envoyé par Uther Voir le message
    C'est difficile de reprocher aux gens de ne pas utiliser les bons outils quand ils ne sont pas facilement identifiables.
    Je suis d'accord que le comité n'a pas explicitement déprécier beaucoup de syntaxes, pour autant, je suis pas d'accord avec le "pas facilement identifiables". Les problèmes de sécurité du code et les bonnes pratiques sont des choses qui sont largement documenté depuis plus de 20 ans, dans des livres, des blogs, des talks, etc. Les raisons que j'ai entendu le plus souvent pour la non utilisation des "bonnes pratiques", c'est pas "je savais pas que ca existait", mais :

    - "ca marche bien comme ca, avec mon vieux code" (non, tu teste comme un singe et c'est pour ca que tu vois pas les bugs)
    - "je dois maintenir du code legacy" (ca n'empêche pas de faire évoluer le code et c'est aussi ton boulot d'expert d'expliquer aux décideurs le cout de maintenir le code legacy plutôt que le faire évoluer)
    - "pas le temps de me former" (et c'est pour ça que tu es obsolète et que ton code est mauvais)
    - etc

    Citation Envoyé par Uther Voir le message
    je doute que ça ait une importance énorme sur les chiffres de vulnérabilité des gros projets.
    Je vais être dans l'appréciation personnelle, mais globalement, je trouve qu'il y a encore beaucoup de bugs qui sont facilement détectables par les compilateurs et les sanitizers, même sur des projets critiques. Tous ces bugs ne finissent pas en vulnérabilité majeur (comme Heartbleed, qui était un problème de bound check), mais ca reste des bugs assez courants.

    Mais, dans la même idée, les erreurs évitables par Rust sont qu'une (petite) partie des bugs que l'on retrouve sur les applications. Quand on regarde par exemple la publication des vulnérabilités sur OpenSSL, c'est beaucoup des erreurs de logique, des choses qui ne sont pas détectables par Rust ou des sanitizers. Je pense que c'est dans ce sens que Stroustrup parlait de sécurité globale. Je suis juste pas du tout convaincu, pour le moment, que l'utilisation de Rust aura un impact significatif sur mon travail de tous les jours et la qualité de mes codes.

    Citation Envoyé par Uther Voir le message
    mais je vois mal comment faire un C++ aussi sécurisé que Rust sans déprécier tellement de choses que ça en deviendrait presque un dialecte séparé, et ça poserait énormément de défis avec l'historique de C++. Je ne suis pas certain que ça serait faisable facilement au sein du comité.
    Il n'y a justement pas besoin de quoi que ce soit de la part du comité. C'est juste une question de choix de la part des devs de ne plus utiliser certaines syntaxes, certains idioms, suivre certaines pratiques, sans qu'il soit nécessaire de déprécier quoi que ce soit.

    C'est ce que je critique le plus dans la comparaison entre Rust et le C++ : je pense pas qu'il y a besoin qu'une chose soit dans le langage ou fait par le comité.

    Citation Envoyé par Uther Voir le message
    Parier sur les évolutions d'un langage, c'est beaucoup plus spéculatif. C'est sympathique dans un forum de programmeurs, mais j’éviterais vraiment pour toute décision sérieuse.
    Il ne s'agit pas réellement de spéculer sur les évolutions futures des outils, mais il faut quand même faire des choix maintenant à partir d'informations incomplètes et de spéculations. Si on démarre un nouveau projet, qui ne nécessite pas de bibliothèques exotiques, et qui peut être autonomes, pourquoi pas Rust. Il faut quand même évaluer le coût de l'ajout d'une nouvelle stack technique (formation, devs, infrastructure, etc). Par contre, pour un projet existant, faut-il préférer faire la migration (avec le coût que l'on aura a faire cette migration et le risque d'avoir des points de blocage sur les libs) et faire évoluer le code existant.

    Mon pari est que l'on peut, pour le moment, attendre avant de faire cette migration. L'amélioration du code avec les outils et pratiques existantes apportent déjà beaucoup pour avoir un code sécurisé. Et ma spéculation, c'est que les outils vont évoluer (= piquer les idées de Rust) pour améliorer encore cette sécurité. (Et c'est pas un choix que j'ai fait sur un forum, mais au boulot).

    Mais, pour conclure, ça sera vraiment une question d'estimation personnelle sur la possibilité d'obtenir de la sécurité. Mais, comme je l'ai dit : Je suis juste pas du tout convaincu, pour le moment, que l'utilisation de Rust aura un impact significatif sur mon travail de tous les jours et la qualité de mes codes.

  8. #48
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 490
    Points
    15 490
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Je suis d'accord que le comité n'a pas explicitement déprécier beaucoup de syntaxes, pour autant, je suis pas d'accord avec le "pas facilement identifiables". Les problèmes de sécurité du code et les bonnes pratiques sont des choses qui sont largement documenté depuis plus de 20 ans, dans des livres, des blogs, des talks, etc.
    Les bonne pratiques ça clairement ces limites. Tu as des gens plus ou moins formés, avec une pratique plus ou moins avancée. Malgré une formation, on peut facilement avoir de mauvaises conceptions. Par exemple, contrairement à ce que tu disais, il ne suffit pas d'utiliser vector ou string : il faut aussi faire attention à comment on les utilise. Je suppose que tu étais bien au courant et que tu as expliqué ça de manière un trop simplifiée, mais c'est typiquement le genre de soucis qui va arriver, que ça soir par mauvaise compréhension du concept ou inattention à l'utilisation.
    Les usages à risques sont plus difficile a voir dans la pratique que dans les exemple de cours. Même les experts, à jour, et qui pratiquent en permanence, finissent fatalement par faire des erreurs car les fonctionnalités problématique sont trop facilement accessible par inadvertance.

    Le fait que le compilateur te refuses simplement les usages à risque change complètement la donne.

    Citation Envoyé par mintho carmo Voir le message
    Les raisons que j'ai entendu le plus souvent pour la non utilisation des "bonnes pratiques", c'est pas "je savais pas que ca existait", mais :
    - "ca marche bien comme ca, avec mon vieux code" (non, tu teste comme un singe et c'est pour ca que tu vois pas les bugs)
    - "je dois maintenir du code legacy" (ca n'empêche pas de faire évoluer le code et c'est aussi ton boulot d'expert d'expliquer aux décideurs le cout de maintenir le code legacy plutôt que le faire évoluer)
    - "pas le temps de me former" (et c'est pour ça que tu es obsolète et que ton code est mauvais)
    - etc
    C'est la dure loi de la réalité et on ne peut pas faire comme si ça n'existait pas.
    C'est une bonne partie de la raison pour laquelle le fait que le langage ne tolère pas de cacher facilement la merde sous le tapis est utile.

    Citation Envoyé par mintho carmo Voir le message
    Mais, dans la même idée, les erreurs évitables par Rust sont qu'une (petite) partie des bugs que l'on retrouve sur les applications. Quand on regarde par exemple la publication des vulnérabilités sur OpenSSL, c'est beaucoup des erreurs de logique, des choses qui ne sont pas détectables par Rust ou des sanitizers. Je pense que c'est dans ce sens que Stroustrup parlait de sécurité globale. Je suis juste pas du tout convaincu, pour le moment, que l'utilisation de Rust aura un impact significatif sur mon travail de tous les jours et la qualité de mes codes.
    J'ai regardé vite fait les CVE d'OpenSLL de cette année. C'est environ 40% de toutes les CVE qui sont dues à gestion mémoire, ça monte à 60% si regarde les CVE de sévérité moyenne ou plus. C'est globalement ce qu'on constate sur la plupart des projets C++ conséquents : environ les deux tiers des vulnérabilités importantes sont liées à des problèmes de sécurité mémoire.

    Citation Envoyé par mintho carmo Voir le message
    Il n'y a justement pas besoin de quoi que ce soit de la part du comité. C'est juste une question de choix de la part des devs de ne plus utiliser certaines syntaxes, certains idioms, suivre certaines pratiques, sans qu'il soit nécessaire de déprécier quoi que ce soit.
    Sauf que la pratique a démontré que ça ne marche pas. C'est ce qu'entent Biarne Stroustrup quand il dit "Being careful does not scale". Sur un code suffisamment compliqué il y aura forcément une mauvaises utilisations involontaires si on ne met pas en place des garde-fous.

  9. #49
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 685
    Points
    685
    Par défaut
    Citation Envoyé par Uther Voir le message
    Les bonne pratiques ça clairement ces limites.

    finissent fatalement par faire des erreurs car les fonctionnalités problématique sont trop facilement accessible par inadvertance.

    C'est ce qu'entent Biarne Stroustrup quand il dit "Being careful does not scale". Sur un code suffisamment compliqué il y aura forcément une mauvaises utilisations involontaires si on ne met pas en place des garde-fous.
    Je pense qu'il y a une confusion avec le "being careful". Si on se dit par exemple "on n'utilise pas void*" (c'est à dire interdire une syntaxe qui n'est pas safe du tout), c'est pas une erreur que l'on va faire par inattention. L'argument "being safe" est utilisé par exemple pour les pointeurs en C, où les devs vont dire que le code sera correct si on fait bien attention d'appeler correctement le delete. Ce qui peut être ok comme approche dans un petit code, mais qui est ingérable en pratique quand la taille du code augmente ("Being careful does not scale"). Et les erreurs qui en découle peuvent être très compliqué a détecté (en particulier les dangling ptr), même avec des outils.

    C'est très différent du problème des bonnes pratiques. Si on dit "on utilise uniqur_ptr et shared_ptr partout", on se retrouve pas a utiliser involontairement des pointeurs nus par erreur. Et globalement, quand on voit les erreurs dans les CVE, c'est pas du mauvais code écrit par inadvertance, c'est un choix volontaire d'écrire du code old school (plutôt du C compilé avec un compilateur C++) dont on sait qu'il est facile de faire des erreurs. Quand on se met des bonnes pratiques de codage qui interdisent certaines syntaxes non safe, c'est pas très compliqué a vérifier lors des reviews du code (voire même via des checks automatiques lors des commits).

    On aura toujours des bugs, même avec Rust. Mais pour moi, ce qu'essaie d'expliquer Stroustrup quand il parle de "safe C++", c'est qu'il est possible d'avoir un niveau de sécurité équivalent à Rust en C++ sans justement utiliser l'argument "being careful" et donc en évitant les mauvaises utilisations involontaires. Et c'est mon impression aussi. En tout cas, de mon expérience, quand je voyais des gros problèmes de qualité de code en C++, c'était des choix volontaires de la part des devs. Et c'est pas un problème de compétences, je bosse régulièrement avec des débutants et ils apprennent facilement les bonnes pratiques.

    Citation Envoyé par Uther Voir le message
    J'ai regardé vite fait les CVE d'OpenSLL de cette année. C'est environ 40% de toutes les CVE qui sont dues à gestion mémoire, ça monte à 60% si regarde les CVE de sévérité moyenne ou plus. C'est globalement ce qu'on constate sur la plupart des projets C++ conséquents : environ les deux tiers des vulnérabilités importantes sont liées à des problèmes de sécurité mémoire
    Je parlais des bugs en general, pas que des CVE. Bon ok, le cas de OpenSSL est probablement un peu particulier, parce que un bug peut devenir très rapidement une vulnérabilité chez eux Mais pour un dev "normal", le gros de son boulot ne sera généralement pas des vulnérabilités critiques toute la journée et c'est dans ce sens que je disais que passer Rust n'aurait aucun impact sur mon boulot, en terme de temps de dev, de bugs et de vulnérabilités.

  10. #50
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 469
    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 469
    Points : 6 102
    Points
    6 102
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Si un nouveau projet devait démarrer en C++, mais avec des devs qui sont formés, avec un code from scratch et un design orienté vers la sécurité, en mettant en place les outils, etc. est-ce qu'on n'aurait pas une sécurité équivalente à Rust ?
    Non. Le niveau de sécurité du "C++ moderne" sera plus proche, mais ne sera pas équivalent à celui de Rust.

    Admettons que ce nouveau projet C++ suive les bonnes pratiques et ne dépende que de bibliothèques qui suivent aussi les bonnes pratiques.
    Certes, sur certains aspects, le niveau sera équivalent. Par exemple, le RAII éliminera les double free et il n'y aura pas plus de fuites de mémoire que dans un langage avec ramasse-miettes.
    Par contre, d'autres garanties de Rust resteront absentes dans le projet C++, comme l'absence de dandling pointer. Les durées de vie des pointeurs et références ne font pas partie du système de types en C++.

    Si tu approfondis Rust, tu verras aussi des contrôles statiques intéressants pour la programmation concurrente.

  11. #51
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 685
    Points
    685
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    comme l'absence de dandling pointer. Les durées de vie des pointeurs et références ne font pas partie du système de types en C++.
    A moins qu'on ne parle pas de la même chose, c'est difficile (*) d'avoir un dangling ptr avec unique_ptr ou shared_ptr. Release et reset remettent le pointeur a null, ce qui cause un crash dans tous les cas, pas un dangling ptr avec le risque d'un Heisenbug.

    (*) a moins de faire un truc volontairement idiot, comme `delete p.get()`. Mais ça sera pas juste une erreur d'inattention.

    Alors, ok, c'est mieux d'avoir un check a la compilation, pour avoir une détection plus tôt du problème. Mais on aura quand même une détection du problème.

    Pour les références, le passage d'un pointeur vers une référence peut poser problème si on fait n'importe quoi, mais c'est aussi un choix volontaire et explicite de faire de telles conversions. (D'ailleurs, cette opération est `unsafe` aussi en Rust, c'est au dev de savoir ce qu'il fait). Les cas triviaux, comme returner une reference sur une variable locale est détectée sans problème.

    Citation Envoyé par Pyramidev Voir le message
    Si tu approfondis Rust, tu verras aussi des contrôles statiques intéressants pour la programmation concurrente.
    Sans lib et sans bonnes pratiques, c'est vrai que le C++ n'est pas forcément simple pour la concurrence. Il y a pleins de libs qui proposent les patterns classiques de concurrence et qui évitent les problèmes et simplifie le code. Et on peut améliorer la détection des problèmes avec ThreadSanitizer. Mais je suis d'accord que c'est améliorable.

    Citation Envoyé par Pyramidev Voir le message
    Non. Le niveau de sécurité du "C++ moderne" sera plus proche, mais ne sera pas équivalent à celui de Rust.
    Mon propos n'est pas de dire que le niveau de sécurité est équivalent actuellement et avec la même énergie dépensée. Mais plutôt de dire que si on a le choix entre passer un gros projet sur Rust (avec ce que cela coute : former les devs, mettre en place l'infrastructure, réécrire tout le code, etc) et ou continuer à améliorer le projet en C++ (en acceptant aussi d'avoir des couts pour la formation des devs, mettre en place les outils, etc), alors je pense que le second choix est complètement raisonnable (pour l'instant), parce qu'on n'aura pas forcément un gain en terme de qualité de code, de sécurité, de coûts de maintenance, etc. Et mon pari/prédiction est que le langages et les outils dans le future rendront le C++ encore plus proche de Rust en termes de sécurité (et donc rendront encore moins pertinent les coûts de migration du C++ vers Rust pour un gros projet existant).

  12. #52
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 490
    Points
    15 490
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Je pense qu'il y a une confusion avec le "being careful". Si on se dit par exemple "on n'utilise pas void*" (c'est à dire interdire une syntaxe qui n'est pas safe du tout), c'est pas une erreur que l'on va faire par inattention.
    Sauf que les règles à respecter sont très nombreuses et pas toujours aussi simple. Avoir un moyen de bloquer ces cas dans le langage plutôt que de compter sur le fait que les programmeurs feront tout comme il faut, ça change tout.

    Citation Envoyé par mintho carmo Voir le message
    Quand on se met des bonnes pratiques de codage qui interdisent certaines syntaxes non safe, c'est pas très compliqué a vérifier lors des reviews du code (voire même via des checks automatiques lors des commits).
    Les check automatiques, c'est en effet l'idée de la sécurisation à l'échelle. Le borrow checker en Rust qui garantit la sécurité mémoire, c'est plus ou moins un analyseur statique comme on a en C++.
    Mais pour que ça détecte efficacement les problème mémoire, il a fallu limiter les pattern qui n'étaient pas vérifiable aux bloc unsafe. Si C++ veut atteindre le même niveau de garantie de sécurité, il faudra qu'il trouve un système similaire. Le système de profil qu'esquisse Bjarne Stoupstrup semble permettre ça, mais ça reste très vague pour le moment. Le problème est que le poids de l'historique rend ça compliqué.

    Citation Envoyé par mintho carmo Voir le message
    Je parlais des bugs en general, pas que des CVE. Bon ok, le cas de OpenSSL est probablement un peu particulier, parce que un bug peut devenir très rapidement une vulnérabilité chez eux Mais pour un dev "normal", le gros de son boulot ne sera généralement pas des vulnérabilités critiques toute la journée et c'est dans ce sens que je disais que passer Rust n'aurait aucun impact sur mon boulot, en terme de temps de dev, de bugs et de vulnérabilités.
    En effet on ne parle pas de bug lambda, mais de failles sécurité : des problèmes qui peuvent permettre a un tiers de détourner le logiciel à leur fin (accès à des données privées, prise de contrôle, deni de service, ...). Rust ne prétend évidement pas empêcher les bugs de logique, quoique il possède quand même quelques particularités comme un typage bien plus strict qui aident quand même pas mal sur le sujet. Par contre, c'est plus dur a quantifier.

    Citation Envoyé par mintho carmo Voir le message
    Release et reset remettent le pointeur a null, ce qui cause un crash dans tous les cas, pas un dangling ptr avec le risque d'un Heisenbug.
    La norme ne garantit pas un crash propre dans ce cas. Déréférencer un pointeur nul est explicitement indiqué comme un comportement indéfini. Un compilateur est libre de faire n'importe quoi si ça l'arrange, pour des raisons d'optimisation par exemple.

  13. #53
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 469
    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 469
    Points : 6 102
    Points
    6 102
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    A moins qu'on ne parle pas de la même chose, c'est difficile (*) d'avoir un dangling ptr avec unique_ptr ou shared_ptr. Release et reset remettent le pointeur a null, ce qui cause un crash dans tous les cas, pas un dangling ptr avec le risque d'un Heisenbug.
    Si un objet contient des pointeurs ou références vers d'autres objets, il n'y a pas de garantie statique que cet objet vit bien moins longtemps que tous les objets vers lesquels il contient directement ou indirectement un pointeur ou une référence.

    Est-ce que ça fait partie des cas où tu remplaces les pointeurs et références par des std::shared_ptr, juste pour être sûr de ne pas avoir de dandling pointer ou dandling reference ? En Rust, si on pense qu'un objet vit forcément moins longtemps qu'un autre, on peut utiliser une référence sans avoir peur.

    D'ailleurs, y a-t-il des cas où tu te retiens de stocker dans un objet un std::string_view et où tu préfères stocker directement une copie de chaîne sous forme de std::string ? En Rust, dans ce genre de cas, on n'est pas obligé de sacrifier les performances. Si la châine d'origine peut être désallouée plus tôt que prévu, le compilateur râlera.

    Citation Envoyé par mintho carmo Voir le message
    Pour les références, le passage d'un pointeur vers une référence peut poser problème si on fait n'importe quoi, mais c'est aussi un choix volontaire et explicite de faire de telles conversions. (D'ailleurs, cette opération est `unsafe` aussi en Rust, c'est au dev de savoir ce qu'il fait).
    En C++, dans le cas où le pointeur est utilisé avec une sémantique de référence optionnelle, le type d'étourderie qui peut arriver est si on déréférence le mauvais pointeur par étourderie, par exemple après un copier-coller qu'on n'a pas assez modifié :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if (user_2 != nullptr) {
        handle_user(*user_1); // oops, should have been handle_user(*user_2)
    }
    Si on traduit mot-à-mot en Rust (non idiomatique) avec user_2 de type Option<User&>, on aura alors ceci :

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if user_2.is_some() {
        handle_user(unsafe { user_1.unwrap_unchecked() });
    }
    On peut bloquer l'unsafe Rust à l'échelle du crate. En safe Rust toujours pas idiomatique, le code devient :

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if user_2.is_some() {
        handle_user(user_1.unwrap());
    }
    Il y aura alors un contrôle au runtime et le code paniquera à l'exécution.
    Cela dit, un développeur en début d'apprentissage du Rust aura plus de chance d'écrire :

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    match user_2 {
        Some(user) => handle_user(user),
        None => {}
    }
    Ici, la variable user n'existe que dans la branche dans laquelle l'utilisateur 2 optionnel existe. Par analogie au C++, c'est un peu comme si le compilateur vérifiait à la compilation qu'on ne déréférence le pointeur que dans le if qui vérifie que le pointeur n'est pas nul.
    Remarque : le code précédent peut se réécrire :

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if let Some(user) = user_2 {
        handle_user(user);
    }

    Citation Envoyé par mintho carmo Voir le message
    Mon propos n'est pas de dire que le niveau de sécurité est équivalent actuellement et avec la même énergie dépensée. Mais plutôt de dire que si on a le choix entre passer un gros projet sur Rust (avec ce que cela coute : former les devs, mettre en place l'infrastructure, réécrire tout le code, etc) et ou continuer à améliorer le projet en C++ (en acceptant aussi d'avoir des couts pour la formation des devs, mettre en place les outils, etc), alors je pense que le second choix est complètement raisonnable (pour l'instant), parce qu'on n'aura pas forcément un gain en terme de qualité de code, de sécurité, de coûts de maintenance, etc. Et mon pari/prédiction est que le langages et les outils dans le future rendront le C++ encore plus proche de Rust en termes de sécurité (et donc rendront encore moins pertinent les coûts de migration du C++ vers Rust pour un gros projet existant).
    En entreprise, réécrire un code volumineux coûte cher, donc n'est pas un choix qui se fait à la légère.

    Si jamais le code a tellement de dette technique qui ralentit tellement les développements que l'entreprise est prête à investir dans une réécriture d'une grosse partie du projet alors, au lieu de réécrire cette partie en C++ propre, je privilégierais plutôt de l'écrire en Rust.

  14. #54
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 469
    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 469
    Points : 6 102
    Points
    6 102
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Si un objet contient des pointeurs ou références vers d'autres objets, il n'y a pas de garantie statique que cet objet vit bien moins longtemps que tous les objets vers lesquels il contient directement ou indirectement un pointeur ou une référence.
    Justement, je viens de tomber sur un article publié aujourd'hui avec un exemple sympathique : A curiously recurring lifetime issue.

    L'article donne l'exemple d'un bout de code :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
      const capnp::List<std::uint64_t>::Reader list =
          request.send().wait(wait_scope).getList();
    L'auteur du code pensait que getList retournait un objet qui avait l'ownership. Manque de bol, cet objet n'avait pas l'ownership et avait besoin que l'objet créé par l'expression request.send().wait(wait_scope) reste en vie.

    Le correctif est alors :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
      auto response = request.send().wait(wait_scope); // 👈 ADDED
      const capnp::List<std::uint64_t>::Reader list =
          response.getList();
          // ☝️ CHANGED
    Ainsi, l'objet rangé dans la variable response n'est plus un objet temporaire et vit plus longtemps que l'objet qui se trouve dans la variable list.

    En Rust, par contre, on aurait eu une erreur de compilation. En plus, le message d'erreur du compilateur aurait indiqué comment corriger le code (voir les détails dans l'article).

  15. #55
    Membre à l'essai
    Femme Profil pro
    Étudiant
    Inscrit en
    Octobre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2012
    Messages : 7
    Points : 14
    Points
    14
    Par défaut
    Chaque langage a ses avantages et ses inconvénients.
    Rust met en avant la sécurité mémoire, mais je lui vois surtout un écosystème plus pratique que C et C++ (cargo, arborescence de projet standardisée, 1 seul compilateur/lib standard officiel, cross compilation triviale, librairies réutilisables).
    D'un autre côté c'est un langage plus bas niveau que C++, pas bien adapté pour coder la logique métier d'une application desktop.

    C++ a un écosystème et une lib standard pas top, difficilement portable (pas d'unicode), mais le langage lui même est très poussé.
    Il permet de créer de très bons frameworks, ex Qt.

    Dans les développements que je fait, la sécurité mémoire n'est pas très importante.

    La plupart des autres langages à la mode conviennent mal aux interfaces graphiques parce qu'ils sont garbage collectés

  16. #56
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    25
    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 : 25
    Points : 90
    Points
    90
    Par défaut
    Citation Envoyé par kiruahxh Voir le message
    D'un autre côté c'est un langage plus bas niveau que C++, pas bien adapté pour coder la logique métier d'une application desktop.
    Qu'entendez-vous par bas niveau ou haut niveau ici? Les deux langages permettent des manipulations bas niveau, et les deux langages sont multi-paradigmes et permettent des constructions abstraites et de haut niveau.
    Et pour ce qui est de Rust, les mécanismes de traits associés aux types génériques, aux possibilités qu'on a de les conditionner, et aux systèmes de macro permettent de cibler très finement les aspect de la logique métier que l'on souhaite implémenter et mettre à disposition d'un utilisateur tiers.

  17. #57
    Communiqués de presse

    Femme Profil pro
    Traductrice Technique
    Inscrit en
    Juin 2023
    Messages
    906
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 906
    Points : 63 531
    Points
    63 531
    Par défaut La Maison Blanche publie un rapport appelant à réduire la surface d'attaque dans le cyberespace
    Les futurs logiciels devraient être sûrs pour la mémoire, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyber-attaques.

    L'Office of the National Cyber Director (ONCD) de la Maison Blanche a publié un rapport appelant la communauté technique à réduire de manière proactive la surface d'attaque dans le cyberespace. De leur côté, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyberattaques.

    L'ONCD fait valoir que les fabricants de technologies peuvent empêcher des catégories entières de vulnérabilités d'entrer dans l'écosystème numérique en adoptant des langages de programmation sans danger pour la mémoire. L'ONCD encourage également la communauté des chercheurs à se pencher sur le problème de la mesurabilité des logiciels afin de permettre le développement de meilleurs diagnostics mesurant la qualité de la cybersécurité.

    Le rapport s'intitule “Back to the Building Blocks: A Path Toward Secure and Measurable Software.

    "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", a déclaré Harry Coker, directeur national du cyberespace. "Grâce au travail de l'équipe de l'ONCD et à l'excellente collaboration de la communauté technique et de nos partenaires des secteurs public et privé, le rapport publié aujourd'hui décrit les menaces et les possibilités qui s'offrent à nous alors que nous nous dirigeons vers un avenir où les logiciels seront sans danger pour la mémoire et sécurisés dès leur conception. Je me réjouis également que nous travaillions avec la communauté universitaire et que nous fassions appel à elle pour nous aider à résoudre un autre problème difficile : comment développer de meilleurs diagnostics pour mesurer la qualité de la cybersécurité ? Il est impératif de relever ces défis pour garantir la sécurité à long terme de notre écosystème numérique et protéger la sécurité de notre pays".


    En adoptant une approche de l'élaboration des politiques axée sur l'ingénierie, l'ONCD veille à ce que l'expertise de la communauté technique se reflète dans la manière dont le gouvernement fédéral aborde ces problèmes. Les créateurs de logiciels et de matériel peuvent avoir un impact considérable sur la sécurité partagée de la nation en intégrant les résultats de la cybersécurité dans le processus de fabrication.

    "Certains des événements cybernétiques les plus tristement célèbres de l'histoire - le ver Morris de 1988, le ver Slammer de 2003, la vulnérabilité Heartbleed de 2014, l'exploit Trident de 2016, l'exploit Blastpass de 2023 - ont été des cyberattaques qui ont fait la une des journaux et qui ont causé des dommages réels aux systèmes sur lesquels la société s'appuie chaque jour. Toutes ces attaques ont une cause fondamentale commune : les vulnérabilités de la sécurité de la mémoire. Depuis trente-cinq ans, les failles de sécurité de la mémoire sont un fléau pour l'écosystème numérique, mais il n'est pas nécessaire qu'il en soit ainsi", déclare Anjana Rajan, directrice nationale adjointe de la cybernétique pour la sécurité technologique. "Ce rapport a été créé par des ingénieurs pour des ingénieurs, car nous savons qu'ils peuvent prendre des décisions en matière d'architecture et de conception des composants qu'ils consomment, ce qui aura un effet considérable sur notre capacité à réduire la surface des menaces, à protéger l'écosystème numérique et, en fin de compte, la nation."

    L'ONCD s'est engagé auprès d'un groupe diversifié de parties prenantes, les ralliant à l'effort de l'administration.

    Conformément à deux thèmes majeurs de la stratégie nationale de cybersécurité du président publiée il y a près d'un an, le rapport publié marque une étape importante dans le transfert de la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grandes organisations, telles que les entreprises technologiques et le gouvernement fédéral, qui sont plus à même de gérer une menace en constante évolution. Ces travaux s'inscrivent également dans le prolongement des programmes "secure by design" et des efforts de recherche et de développement déployés par l'ensemble du gouvernement fédéral, notamment par la CISA, la NSA, le FBI et le NIST, et s'appuient sur eux.

    Les travaux sur la sécurité des mémoires présentés dans le rapport complètent l'intérêt du Congrès pour ce sujet. Il s'agit notamment des efforts des commissions des crédits du Sénat et de la Chambre des représentants des États-Unis, qui ont inclus dans la législation sur les crédits de l'exercice fiscal 2023 un libellé de rapport directif exigeant un exposé de l'ONCD sur cette question. En outre, le président de la commission sénatoriale de la sécurité intérieure et des affaires gouvernementales, Gary Peters (D-MI), et le sénateur Ron Wyden (D-OR) ont fait part à l'ONCD de leurs efforts législatifs en matière de sécurité de la mémoire.


    Lire le rapport complet : Retour aux éléments de base : un chemin vers des logiciels sûrs et mesurables, un rapport de la Maison Blanche sur la sécurité de la mémoire et sur la qualité de la cybersécurité


    Source : Communiqué de presse de la Maison Blanche

    Et vous ?

    Pensez-vous que ce rapport est crédible ou pertinent ?
    Quel est votre avis sur le sujet ?

    Voir aussi :

    Les Agences des Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust, qui « offre de meilleures garanties de sécurisation des plages mémoire des logiciels »

    Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA. L'utilisation d'un langage de programmation à sécurité mémoire comme Rust serait une solution

    La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels
    Images attachées Images attachées  
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  18. #58
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 837
    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 837
    Points : 51 397
    Points
    51 397
    Par défaut La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust
    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

    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.

    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)); 
    }

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

  19. #59
    Membre confirmé Avatar de Issam
    Inscrit en
    Mars 2002
    Messages
    578
    Détails du profil
    Informations personnelles :
    Âge : 48

    Informations forums :
    Inscription : Mars 2002
    Messages : 578
    Points : 604
    Points
    604
    Par défaut
    heuu 1 sec ,


    c'est quoi le rapport entre la maison blanche et les languages de programmation ?

  20. #60
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 548
    Points : 3 945
    Points
    3 945
    Par défaut
    les politiques ne savent pas de quoi il parlent.

    le rust pour remplacer le c => ok
    le rust pour remplacer le c++ => pas totalement ok

Discussions similaires

  1. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 13h51
  2. Index TIOBE du classement des langages de programmation
    Par Gordon Fowler dans le forum Actualités
    Réponses: 564
    Dernier message: 13/01/2013, 18h51
  3. Passer des paramètres à un programme
    Par Cravis dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 08/11/2007, 14h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 02/04/2006, 23h03

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