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. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 660
    Points : 20 558
    Points
    20 558

    Par défaut Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que Rust et Swift

    Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que les nouveaux langages,
    selon Alex Gaynor

    Le monde informatique et plus particulièrement le domaine de la programmation n’a pas l’habitude de délaisser les technologies qu’il a vues naître notamment les langages de programmation. Le Cobol a traversé pas mal de décennies déjà et a fêté, il y a peu, ses soixante ans, le C est toujours en activité et répond présent lorsqu’il s’agit de développer ou de construire des systèmes d’exploitation et, même si le Fortran et le Pascal ou encore le langage Haskell ne couvrent plus une grande partie de la communauté, ils existent toujours et sont utilisés par quelques développeurs. Pourtant les nouveaux langages sont là. Ces derniers que plusieurs appellent les jeunes langages, promettent la robustesse, moins ou l’absence de vulnérabilités, la sécurité par défaut ainsi que de la rapidité.

    Ces nouveaux langages sont-ils plus utiles que les anciens ? Si oui, faudrait-il que les développeurs pensent à faire le saut vers ces langages ? Selon Alex Gaynor, un ingénieur, qui a souligné quelques défauts du C et du C++ dans un billet de blog, il est plus que temps pour que les développeurs pensent à migrer vers d’autres langages plus modernes comme Rust, le langage développé par Mozilla Research ou Swift, car, dit-il, ces langages sont sécurisés par défaut. Cependant, dans la plupart du temps, la conception de ces nouveaux langages de programmation a été fortement influencée par l'expérience acquise avec les langages précédents, qu’il s’agisse de la syntaxe ou encore d’autre chose. Le langage Rust par exemple est lui fortement influencé par le C et le C++.

    Même si c’est le cas, Alex considère néanmoins ces langages plus sécurisés que leurs prédécesseurs, le C vieux d’un peu moins de 50 ans et le C++ apparu courant 1983. D’après les tests présentés et les explications d’Alex Gaynor, le C et C++ induisent un nombre très considérable de failles de sécurité au sein des applications dont ils sont l’outil de conception. « Ma conclusion basée sur l'examen des preuves de nombreux projets logiciels de grande envergure utilisant C et C ++, est qu'il est nécessaire de migrer notre secteur vers des langages sécurisés par défaut tels que Rust et Swift », propose-t-il comme solution aux nombreux problèmes qu’il a soulignés.

    Il estime que, même si le C++, dans sa forme moderne, a apporté quelques fonctionnalités remarquables comme les pointeurs intelligents pour résoudre un certain nombre de ces problèmes, il n’en demeure pas moins qu’il « ne nous sauvera pas ». Alex assure que tous les soucis de vulnérabilité que présente le C++ ne peuvent pas être résolus par les idiomes ou les syntaxes modernes qui lui sont apportées. Ainsi, dans son billet, il met en évidence un certain nombre d'idiomes C++ complètement modernes qui génèrent des vulnérabilités. Il a noté des vulnérabilités permettant de masquer la référence use-after-free et une de ses variantes qui consiste à utiliser le support lambda de C++ pour masquer également une référence, ainsi que d’autres vulnérabilités au sein de la bibliothèque standard du C++, la STL, notamment au niveau des structures de données.

    Nom : z1.png
Affichages : 14385
Taille : 190,8 Ko
    Alex Gaynor

    Il affirme que comme toutes les structures de données STL, la méthode operator[] de span n'effectue aucune vérification des limites. Ceci, dit-il, est regrettable, car l’opérateur[] est la façon la plus ergonomique et la plus simple d’utiliser les structures de données. Il continue en disant que std::vector et std::array peuvent théoriquement au moins être utilisés en toute sécurité, car ils offrent une méthode at() vérifiée (« en pratique, je ne l'ai jamais vue faire, mais vous pouvez imaginer un projet utilisant un outil d'analyse statique. qui a simplement interdit les appels à std::vector<T>::operator[] »). span n'offre pas de méthode at(), ni aucune autre méthode qui effectue une recherche contrôlée par les bornes, a-t-il déclaré.

    Pour finir, Alex affirme que les idiomes modernes en C++ introduisent de nombreux changements susceptibles d’améliorer sa sécurité. Les pointeurs intelligents expriment mieux les durées de vie attendues, std::span vous permet d’avoir toujours une longueur correcte, std::variant fournit une abstraction plus sûre pour les unions. Cependant, continue-t-il, le C ++ moderne introduit également d'incroyables nouvelles sources de vulnérabilités en plus de ceux qu’il a hérités du C. À ce propos, rappelons que le mois passé, WhiteSource a présenté un index selon lequel le langage C serait le langage de programmation le plus vulnérable aux failles de sécurité les plus connues dans la communauté open source.

    WhiteSource a indiqué qu’en dix ans, C a montré un nombre de vulnérabilités très important. Il a été donc placé en tête de la liste des langages les plus vulnérables avec une faiblesse reconnue à 47 % de toutes les vulnérabilités signalées. Pour former le trio des langages présentant le nombre de vulnérabilités le plus élevé, le PHP et le Java suivent respectivement avec 17 % et 12 % des vulnérabilités connues. Le JavaScript vient en quatrième place avec 11 %, le Python et le C++ restent en cinquième place avec 6 % chacun et le Ruby ferme le podium avec un nombre de vulnérabilités open source connu de 5 %. Il a été présenté comme le langage le moins vulnérable parmi les sept langages de l’étude.

    Cela dit, Alex a-t-il raison d’affirmer que les langages Rust ou Swift sont plus sécurisés que le C et le C++ ? Non pour certains adeptes de ces deux langages de programmation. Ils ne sont pas du tout d’accord avec l’index de WhiteSource et encore moins avec ce qu’affirme Alex. Pour eux, le problème n'est pas les langages C/C ++ eux-mêmes, mais que ce sont les développeurs qui implémentent des systèmes sans trop penser à bien les sécuriser comme cela se doit. D’autres expliquent que le C++ se retrouve être un langage de programmation très sécurisé lorsqu’on ne fait pas usage des fonctionnalités qu’il a héritées du C. Le C serait-il le langage en tort ?

    Dans le même temps, certaines donnent raison à Alex Gaynor. « Un problème important que j'ai eu avec C++ est que, même si votre base de code est du pur C++ 17, la bibliothèque standard est un monstre de Frankenstein hérité du C++ moderne qui nécessite de nombreux compromis. Une bibliothèque standard qui présente les capacités du C++ 17 de manière propre devrait supprimer une bonne partie de la compatibilité ascendante dans les environnements C++ modernes », affirme l’un d’entre eux. Pour éviter ce problème, d’autres préfèrent utiliser leurs propres bibliothèques.

    « C++ étant mon langage principal, pour travailler sur mes bases de code, j'ai abandonné la bibliothèque standard et mis en œuvre mon propre remplacement. Je suis sûr que ce n'est pas du tout pratique, mais cela me permet de faire évoluer la bibliothèque avec de nouvelles révisions du standard C++ sans être absolument fixé sur la compatibilité ascendante », a ajouté un autre. De son côté, Alex a continué d’insister sur le fait qu'il serait plus judicieux d’utiliser des langages sécurisés par défaut. « Mon expérience professionnelle avec le C++ relativement moderne et de l’audit du code Rust (y compris du code Rust qui fait un usage important de l’insécurité) est que la sécurité du C++ moderne n’est tout simplement pas la même que celle des langages sûrs comme Rust et Swift », a-t-il déclaré.

    Source : Billet de blog

    Et vous ?

    Êtes-vous du même avis qu'Alex Gaynor ? Pourquoi ?
    Avez-vous aussi été confronté à ces problèmes avec votre code ou dans du code legacy ?
    Faut-il abandonner le C et le C++ pour d'autres langages comme Rust ou Swift comme il le propose ? Pourquoi, selon vous ?

    Voir aussi

    Le langage de programmation Cobol fête ses 60 ans, peut-il encore tenir longtemps face à la concurrence des nouveaux langages ?

    Quel langage de programmation comporte le plus de vulnérabilités en matière de sécurité ? Une étude de WhiteSource

    Quelle est la plateforme de développement ou le langage le plus exposé aux vulnérabilités ? Une étude de Veracode donne des éléments de réponse
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Profil pro
    Spleen
    Inscrit en
    mai 2013
    Messages
    76
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Spleen

    Informations forums :
    Inscription : mai 2013
    Messages : 76
    Points : 77
    Points
    77

    Par défaut

    Je déplore tout de même le faible nombre de commentaires sur des articles très bien rédigés, sans faute de français et bien sourcé qui méritent la lecture.

    Pour eux, le problème n'est pas les langages C/C ++ eux-mêmes, mais que ce sont les développeurs qui implémentent des systèmes sans trop penser à bien les sécuriser comme cela se doit
    Tout est dit selon moi. Il a beau dire, ces exemples sont très TRÈS circonstanciels :
    - Avez-vous déjà trouvé, d'autant plus dans une section critique en production (sachant que certains ne sont disponible qu'en C++17), un std::variant

    Une bibliothèque standard qui présente les capacités du C++ 17 de manière propre devrait supprimer une bonne partie de la compatibilité ascendante dans les environnements C++ modernes
    Faire comme D dès le début, table rase du passé. On sort enfin les ranges, on trouve mieux que ces maudits itérateurs, on vire ces machines à états cin/cout/cerr, on blinde la SL/STL parce que mis à part les conteneurs simples c'est vide en algo…

  3. #3
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 627
    Points : 2 690
    Points
    2 690

    Par défaut

    Citation Envoyé par Spleeen Voir le message
    Je déplore tout de même le faible nombre de commentaires sur des articles très bien rédigés, sans faute de français et bien sourcé qui méritent la lecture.
    C'est en ce moment les "vacances" en RP... donc la ou sont basés la majorité des développeurs...

    Sinon à part ça : Il n'y a rien de mieux que le langage de programmation C pour le développement de systèmes d'exploitation d'après Linus Torvalds
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  4. #4
    Membre régulier
    Femme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    décembre 2017
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 27
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : décembre 2017
    Messages : 21
    Points : 101
    Points
    101

    Par défaut

    C'est qui lui ? Oh un ingénieur. Si c'est un ingénieur, c'est qu'il a forcément raison !!
    Blague à part, c'est écrit où que C++ recherchait la sécurité ? operator[] ne vérifie pas les dépassements, pauvre petit chou. Et alors, si t'en veux pas tu l'utilises pas, mais après c'est qui qui doit se plaindre de ces applications qui bouffent tout le CPU comme s'ils étaient seuls à s'exécuter.

  5. #5
    Membre actif
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    195
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

    Informations forums :
    Inscription : novembre 2005
    Messages : 195
    Points : 232
    Points
    232

    Par défaut

    Bref , un langage sécurisé " par nature " , cela n existe pas , on la vu avec les deux premières versions de Java . C 'est le travail du développeur ça , à la limite du framework , mais c 'est tout

  6. #6
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 852
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 852
    Points : 25 845
    Points
    25 845

    Par défaut

    Citation Envoyé par lsbkf Voir le message
    operator[] ne vérifie pas les dépassements
    Ce qui est voulu mais en plus non toujours vrai.
    Sur vs2017 l'implémentation est la suivante
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    _NODISCARD _Ty& operator[](const size_type _Pos)
    		{	// subscript mutable sequence
     #if _ITERATOR_DEBUG_LEVEL == 2
    		if (size() <= _Pos)
    			{	// report error
    			_DEBUG_ERROR("vector subscript out of range");
    			}
     #elif _ITERATOR_DEBUG_LEVEL == 1
    		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());
     #endif /* _ITERATOR_DEBUG_LEVEL */
     
    		return (this->_Myfirst()[_Pos]);
    		}
    Donc oui il y a vérification en debug, et aucune en release, comme tout bon code devrait logiquement faire.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  7. #7
    Membre régulier
    Femme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    décembre 2017
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 27
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : décembre 2017
    Messages : 21
    Points : 101
    Points
    101

    Par défaut

    Citation Envoyé par Bousk Voir le message
    Donc oui il y a vérification en debug, et aucune en release, comme tout bon code devrait logiquement faire.
    C'est aussi le cas dans GCC (à voir dans quels cas la macro _GLIBCXX_ASSERTIONS est définie), et il y a des chances pour que LLVM soit aussi dans le coup. Mais évidemment c'est plus facile de taper sur C++ dans un billet de blog !

  8. #8
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    585
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 585
    Points : 2 835
    Points
    2 835

    Par défaut

    Citation Envoyé par darklinux Voir le message
    Bref , un langage sécurisé " par nature " , cela n existe pas
    Peut-être, mais certains se le veulent plus que d'autres. Le coup des références invalident est très facile à faire en C++, et à contrario, difficile à diagnostiquer. Un exemple tout bête:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    char const* cstr = to_string(x).c_str();
    foo(cstr); // oups to_string retourne un temporaire et cstr pointeur sur un pointeur désalloué.
    Ok, c_str() sert principalement pour les vieux code ou les bibliothèques C, mais il existe des problèmes similaires avec une lambda qui capture une référence pour lesquels le compilateur ne dira absolument rien. Ce n'est pas pour rien qu'il y a une option -Wlifetime en cours de développement dans clang, même si cela ne pourra pas tout détecter.

    Alors que les langages comme Rust intègre au cœur même du langage une vérification sur le partage et le propriétaire d'une valeur. Le code du genre au-dessus ne compilera simplement pas. Les nouveaux langages essayent aussi d'avoir comportement plus sûr par défaut comme l'immutabilité, pas de conversion implicite, etc et une syntaxe qui laisse moins de place aux erreurs.

    Donc, un langage entièrement sécurisé n'existe probablement pas, mais les langages plus sûrs, si.

    EDIT: Pour libc++ il y a _LIBCPP_DEBUG=1, mais j'ai déjà eu des bugs avec :/. Pour libstdc++, il y _GLIBCXX_DEBUG, plus violent que _GLIBCXX_ASSERTIONS, mais qui change l'abi.

  9. #9
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    mai 2018
    Messages
    488
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Algérie

    Informations forums :
    Inscription : mai 2018
    Messages : 488
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Spleeen Voir le message
    Je déplore tout de même le faible nombre de commentaires sur des articles très bien rédigés, sans faute de français et bien sourcé qui méritent la lecture.
    peut etre parcequ'il n'ya rien a commenter...
    L'article parle juste d'un haineux qui n'aime pas le C++... on vas pas pour autant abandonner le c++ suite a cela... sont article de blog je l'ai déja oublié.
    ce genre d'article de "ouain ouains le langage X est pourrie" tu en as pour tous les langages.

    Aucun langage n'est parfait, donc tous les langage sont critiquitable donc les gens cherche a les critiquer mais nous somme sau dessus de cela et le mieu c'est d'ignorer ce genre d'article comme je le fait.
    voila pouruqoi personne ne commente cela, car cela n'en vaut pas la peine.

  10. #10
    Membre chevronné
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 440
    Points : 1 919
    Points
    1 919

    Par défaut

    Si on cherche la sécurité à tout prix alors il faut éviter d'écrire une seule de code.... Même dans un langage très cadré un développeur peut induire des biais qui seront acceptés par le compilateur et mèneront à la catastrophe...

  11. #11
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 290
    Points : 1 097
    Points
    1 097

    Par défaut

    On peut toujours construire des exemples pour mettre en évidence la faible sécurisation du langage, mais en pratique, c'est un problème surtout pour les débutants ou les programmeurs peu rigoureux, ou peut-être dans des contextes où on demande aux gens de produire du code au kilomètre le plus vite possible et sans grande contrainte pour les performances du produit final.
    Dans ces situations, en effet, il peut y avoir mieux que le C++.
    Pour ce qui est des 'lambda', c'est une construction nouvelle (bien que ça ait déjà 8 ans), je considère que je n'en maitrise pas encore toutes les subtilités, et donc j'évite simplement les constructions trop audacieuses pour l'instant. Après tout, j'écrivais en C++ presque 20 ans avant que ça existe. Et puis il faut aussi un peu de temps pour avoir confiance dans les compilateurs eux-mêmes.

    Je ne connais pas Rust ou Swift, mais j'ai joué un peu avec Julia ces derniers mois. C'est un langage récent, et il y a en effet quelques caractéristiques qui paraissent contribuer à la sécurité (objets immutables par défaut justement), mais la sécurité du langage est très loin dans l'ordre des priorités pour ce que j'ai à faire, j'ai commencé par contrôler les performances en vitesse d'exécution et la gestion de la mémoire.
    Attention, je ne dis pas que la fiabilité des logiciels est sans importance, bien au contraire, mais on peut écrire des logiciels robustes dans n'importe quel langage, même en C.

  12. #12
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    867
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 867
    Points : 2 561
    Points
    2 561

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message

    WhiteSource a indiqué qu’en dix ans, C a montré un nombre de vulnérabilités très important. Il a été donc placé en tête de la liste des langages les plus vulnérables avec une faiblesse reconnue à 47 % de toutes les vulnérabilités signalées. Pour former le trio des langages présentant le nombre de vulnérabilités le plus élevé, le PHP et le Java suivent respectivement avec 17 % et 12 % des vulnérabilités connues. Le JavaScript vient en quatrième place avec 11 %, le Python et le C++ restent en cinquième place avec 6 % chacun et le Ruby ferme le podium avec un nombre de vulnérabilités open source connu de 5 %. Il a été présenté comme le langage le moins vulnérable parmi les sept langages de l’étude.
    Donc, d'après ce paragraphe, c'est plutôt C qui est faiblement sécurisé mais C++ c'est plutôt bon non?

  13. #13
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2011
    Messages
    90
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 90
    Points : 337
    Points
    337

    Par défaut

    Que nous apprend exactement le billet de blog de ce Alex? Strictement rien du tout. Mais là où c'est un peu bizarre c'est que c'est présenté un peu comme s'il avait découvert un truc!
    Disons que le gars avait besoin d'étoffer un peu son blog ...

  14. #14
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 054
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 054
    Points : 3 273
    Points
    3 273

    Par défaut

    Citation Envoyé par Spleeen Voir le message
    Je déplore tout de même le faible nombre de commentaires sur des articles très bien rédigés, sans faute de français et bien sourcé qui méritent la lecture.
    quand tu vois la shitstorm que ça a créé, il vaut mieux ne pas commenter ...
    il n'y a globalement (pas tous les commentaires, mais bon, une grande partie) pas eu une seule remise en question, c'est direct : "il a critiqué le c++, au pilori".
    donc bon, comme je disais dans un autre fil, dans cette époque "moderne" on ne peut plus apprécier quelque chose et être capable d'émettre des critiques sur ce quelque chose.

  15. #15
    Membre extrêmement actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2010
    Messages
    281
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : juillet 2010
    Messages : 281
    Points : 920
    Points
    920

    Par défaut

    C'est malheureusement devenu une habitude, un monde de plus en plus binaire alors que, paradoxalement, on a un accès à des méthodes, un savoir, des possibilités infiniment plus grandes que ce qu'ont eu nos ancêtres... c'est le monde, c'est comme ça, on ne peut rien y faire.

  16. #16
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 852
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 852
    Points : 25 845
    Points
    25 845

    Par défaut

    Citation Envoyé par jo_link_noir Voir le message
    Alors que les langages comme Rust intègre au cœur même du langage une vérification sur le partage et le propriétaire d'une valeur. Le code du genre au-dessus ne compilera simplement pas. Les nouveaux langages essayent aussi d'avoir comportement plus sûr par défaut comme l'immutabilité, pas de conversion implicite, etc et une syntaxe qui laisse moins de place aux erreurs.
    En gros ces langages intègrent dans leur compilateur / phase de compilation de l'analyse de code.
    C'est cool, mais en C++ tu as des outils externes qui le font également. C'est loin d'être parfait - mais peuvent-ils prétendre que celui intégré à Rust ou Swift (ou n'importe quel autre nouveau langage qui vient clâmer sa sécurité "by design") le soit ? - mais y'a donc pas de manque réel. Après s'ils sont pas utilisés...
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  17. #17
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    694
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    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 : 694
    Points : 1 280
    Points
    1 280

    Par défaut C++ est UNIX il fait une seul chose et le fait bien

    C++ est un langage informatique pour convertir du code écrit par un humain en Assembleur efficace. Et il le fait bien, même très bien. Demander d'intégrer de la sécurité se fait généralement au détriment des performances ou de la fonctionnalité bas niveau. Bien des langages ont essayer de faire mieux que C++, jusqu'ici ils ont tous échoués. Le seul véritable challenger est Rust mais il est très récent, pas encore parfaitement éprouvé et un poil moins bon en performances (du moins cela se discute). Et puis ce n'est pas en quelques années que tous va basculer.
    Demander du code propre, sécurisé et facile/rapide a écrire c'est demander l'impossible. Les compilateurs et langages s'améliorent. Mais cela prends du temps et révolutionner le système avec un nième langage ne marche pas car l'on se rends compte au bout d'un moment qu'il a de nouveaux défaut que l'ancien n'avait pas.
    Sécuriser un programme demande du temps, un temps que l'on a jamais en quantité suffisante. Le tout c'est de trouver le bon compromis entre bug/rapidité de développement/efficacité machine... la réponse donne les bonnes méthodes et le bon langage.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  18. #18
    Membre éprouvé
    Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Doctorant en sécurité

    Informations forums :
    Inscription : juin 2013
    Messages : 216
    Points : 1 062
    Points
    1 062

    Par défaut

    Comme tout langage, le C++ à ses avantages et ses inconvénients. Par exemple le C++ est très performant, a une grosse base de code et est très bien supporté mais il laisse la responsabilité de la sécurité au développeur et peut s'avérer fastidieux à écrire.

    Donc il y a des domaines ou il est très bon et d'autre très mauvais. Et c'est un peu simpliste de le critiquer "absolument" ce langage car il y a des domaines ou il est très pertinent.

    C'est comme les gens qui disent "Pour des raisons de sécurité, n’utilisez pas le C!". Ça serait oublier que presque tous les OS sont codés en C et qu'il est bien plus simple de sécuriser du C que des réécrire des bases de codes énormes comme Linux.

    En somme ce n'est pas parce qu'un couteau est moins efficace pour creuser un trou que c'est un outil inutile!

  19. #19
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    585
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 585
    Points : 2 835
    Points
    2 835

    Par défaut

    Citation Envoyé par Bousk Voir le message
    En gros ces langages intègrent dans leur compilateur / phase de compilation de l'analyse de code.
    C'est cool, mais en C++ tu as des outils externes qui le font également. C'est loin d'être parfait - mais peuvent-ils prétendre que celui intégré à Rust ou Swift (ou n'importe quel autre nouveau langage qui vient clâmer sa sécurité "by design") le soit ?
    Pour le cas des durées de vie d'un objet, oui. Simplement car le compilateur vérifie l'intention explicitement indiquée par le développeur et la cohérence de l'ensemble. Alors que les outils d'analyses déduisent l'intention du code... Et vérifie la cohérence par rapport à leur propre déduction. Donc, des faux positifs et des faux négatives. Déduire les propriétés de l'ensemble des chemins prend aussi un temps monstre et il faut au final mettre des annotations.

    Ensuite, les outils d'analyse basés sur llvm pourrait fonctionner aussi efficacement avec tous les langages basés sur llvm: Rust, C, C++, etc. Encore faudrait-il les utiliser, parce que c'est bien joli d'avoir des outils externes efficace, mais bon nombre de développeur ne les connaissent simplement pas. Si cette analyse n'est pas directement dans le compilateur, il y aura toujours des codes foncièrement bogués. On peut espérer quand même que les contrats de C++20 permettront d'avoir un peu plus de vérification au niveau du compilateur.

  20. #20
    Membre averti
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    216
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 216
    Points : 446
    Points
    446

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    Donc, d'après ce paragraphe, c'est plutôt C qui est faiblement sécurisé mais C++ c'est plutôt bon non?
    Oui et non car comme C est le plus utilisé, forcément c'est aussi celui qui va montrer le plus de failles.
    Un peu comme windows qui est nettement moins sécurisé que linux car il a plus de virus...Cela ne prouve rien. Ce qui est plus utilisé montrera forcément plus rapidement et plus souvent des failles.

Discussions similaires

  1. tuer un process quand il nous rend pas la main
    Par lerab51 dans le forum Débuter
    Réponses: 7
    Dernier message: 06/08/2008, 11h35
  2. fichier qui ne se supprime pas car utilisé par un processus
    Par icicmoi dans le forum Windows Forms
    Réponses: 5
    Dernier message: 01/04/2008, 15h16
  3. Réponses: 8
    Dernier message: 28/02/2008, 13h41
  4. Réponses: 4
    Dernier message: 11/05/2007, 17h37
  5. Réponses: 5
    Dernier message: 14/04/2007, 18h47

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