Discussion :

[Bill Fassinou]

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.

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

[Spleeen]

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…

[Mingolito]

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

[ShigruM]

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.

[stardeath]

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.

[sebastiano]

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.

[lsbkf]

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.

[Bousk]

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.

[lsbkf]

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 !

[darklinux]

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

[jo_link_noir]

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.

[sergio_is_back]

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

[wolinn]

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.

[Bousk]

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

[jo_link_noir]

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.

[AoCannaille]

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?

[ParseCoder]

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

[archqt]

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.

[Uther]

C'est qui lui ? Oh un ingénieur. Si c'est un ingénieur, c'est qu'il a forcément raison !!

C'est clair que sortir l'avis d'une personne plutôt lambda, qui n'apporte rien sur un sujet déjà fort connu, je vois pas trop ce que ça fait en news.

Blague à part, c'est écrit où que C++ recherchait la sécurité ? operator[] ne vérifie pas les dépassements, pauvre petit chou.

Le problème est justement que c'est trop facile a utiliser pour quelque chose de potentiellement dangereux. Swift ou Rust permettent les accès non contrôlés si nécessaire pour les performances, mais ils sont explicites pour pousser ceux qui les utilisent à se poser la question de la nécessité de les utiliser.
Un problème récurent en C++ est qu'il y a bien des mécanisme qui permettent une utilisation plus sécurisée, mais eux même introduisent de la complexité et peuvent être mal employés sans que l'on s'en rende compte.

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.

Ce discours valait quand on compare le C++ à des langages managés comme le Python ou le Java. Mais là on parle plutôt de langages compilés moderne sans runtime comme le Rust (et le Swift) qui a prouvé que l'on peut être a la fois sécurisé et avoir des performance identiques au C et C++.

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

Bien sur et on peut démarrer un incendie avec un briquet, alors pourquoi ne pas utiliser un lance flamme pour allumer sa cigarette ?
Ce n'est pas parce qu'aucun langage n'est parfait qu'il n'est pas intéressant de considérer leurs avantages particuliers.

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

Non c'est clairement un problème qui concerne tous les programmeur. On retrouve en permanence des failles, qui ne seraient pas arrivées avec des langages plus sécurisés, dans tous les navigateurs, OS, et autre programmes critiques, qui ne sont pourtant pas codés par des débutants, et qui sont très surveillés niveau sécularité.

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.

Le "peut-être" me parait inadapté car je ne connais quasiment aucune entreprise où le temps n'est pas une contrainte forte.

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.

C'est là où la sécurité est aussi utile à la productivité. En Rust (je connais bien moins Swift) on peut utiliser les lambda sans risques. Au pire le compilateur te dira si ça pose le moindre problème de sécurité.

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.

Je pense que c'est justement un réflexe assez naturel, face à un monde toujours plus vaste au point qu'il peut paraître nous échapper. On peut facilement être tenté de se replier sur ce qu'on connaît, pour avoir un sentiment de sécurité, quitte a passer a coté de beaucoup de choses intéressantes.

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

Les créateur de C++ ont travaillé sur une version les "c++ core guidelines" qui permettent au C++ d'être vérifié statiquement sur l'utilisation de la mémoire. C'est bien, mais niveau garanties ça reste loin de ce que peux faire le Rust qui garantit complètement l'absence d'erreur mémoire et de data race. Le C++ n'a pas été du tout prévu pour ça à la base.

[koala01]

Salut,

Le problème est justement que c'est trop facile a utiliser pour quelque chose de potentiellement dangereux. Swift ou Rust permettent les accès non contrôlés si nécessaire pour les performances, mais ils sont explicites pour pousser ceux qui les utilisent à se poser la question de la nécessité de les utiliser.

Il ne faut pas non plus oublier que toute fonctionnalité (et je parle donc aussi de operator[]) ne vaut que par l'utilisation qui en est faite.

Hé bien, je suis désolé, mais moi qui ne suis pas ingénieur, je sais que, par nature, l'utilisateur (et donc ... moi-même le plus souvent) est un imbécile distrait, et, du coup, j'ai pris le pli de ne jamais lui faire confiance.

Je vais donc utiliser operator[] dans deux cas différents :

Dans le premier cas, je sais que je peux faire confiance aux mécanismes de la classe que j'utilise. C'est le cas "classique" du

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
std::vector<Type> tab;
/* on remplit le tableau à notre guise */
for(size_t i =0; i< tab.size();++i){
    /* on utilise tab[i] à notre convenance */
}

et qu'il n'y aura pas de problème.

Dans le deuxième cas, je n'ai aucun contrôle sur l'indice qui sera utilisé lors de l'appel à operator[], et je vais donc prévoir que l'utilisateur du tableau a fait une erreur de logique. Mon code ressemblera donc à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void foo(std::vector<Type> /* const */ & tab, size_t index){
    assert(index<tab.size() && "index out of bound");
    /* je peux maintenant utiliser tab[index] en toute sécurité */
}

Tu peux tourner les choses comme tu le veux, mes utilisations de operator[] sont safes

Un problème récurent en C++ est qu'il y a bien des mécanisme qui permettent une utilisation plus sécurisée, mais eux même introduisent de la complexité et peuvent être mal employés sans que l'on s'en rende compte.

Heu... tu veux parler de la fonction membre at() de std::vector

Voilà bel et bien une des rares fonctions qui n'auraient jamais du trouver sa place dans la bibliothèque standard; du moins, dans sa version actuelle.

Car il est totalement incohérent d'avoir recours à une exception pour signaler une erreur de logique qui aurait du être corrigée bien avant d'arriver au stade de la production.

Si elle avait utilisé une assertion, susceptible d'être supprimée du code binaire exécutable en production, les choses auraient été différentes

Ce discours valait quand on compare le C++ à des langages managés comme le Python ou le Java. Mais là on parle plutôt de langages compilés moderne sans runtime comme le Rust (et le Swift) qui a prouvé que l'on peut être a la fois sécurisé et avoir des performance identiques au C et C++.

On a toujours bien dit qu'il fallait être particulièrement attentif lorsque l'on décide de coder en C et en C++, car ce sont des langages qui, contrairement à d'autres, mettent énormément le développeur face à ses responsabilités.

Je trouve, quelque part, dommage et surprenant que la personne qui est sensée prendre les responsabilités (car, c'est quelque part le job des ingénieurs) essaye de s'en décharger sur des outils, qui ne seront jamais que cela

Bien sur et on peut démarrer un incendie avec un briquet, alors pourquoi ne pas utiliser un lance flamme pour allumer sa cigarette ?
Ce n'est pas parce qu'aucun langage n'est parfait qu'il n'est pas intéressant de considérer leurs avantages particuliers.

On peut également inverser le raisonnement : bien sur, il n'est pas nécessaire d'utiliser un lance-flammes pour allumer un incendie, un briquet suffit amplement.

Dés lors, ce n'est pas parce que certains langages sont "moins sécurisés" (par rapport aux conneries que les gens sont susceptibles de faire en les utilisant) qu'il faut absolument en chercher d'autres!

Bon dieu, qu'on commence par former correctement les gens, de manière à ce qu'ils soient capables d'utiliser correctement les outils qui leur sont donnés malgré toutes les faiblesses dont ils peuvent souffrir!

Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!

C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!

Non c'est clairement un problème qui concerne tous les programmeur, on retrouve dans tous les navigateurs, OS, ... et autre programmes qui ne sont absolument pas codés par des débutants, et qui sont très surveillés niveau sécurtité, énormément d'erreurs qui ne seraient pas arrivées avec des langages plus sécurisés.

Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt

Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention

Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!

Faut il te faire remarquer que même les programmes codés en Rust (je pense nottemment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?

Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter . Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant

Quelqu'un disait

Ce n'est pas parce que je suis un expert que je ne fais pas d'erreurs. J'en fais simplement moins que les autres

Mais elles sont plus graves que celles commises par le "commun des mortels".

C'est la ou le peut être me parait inadapté car je ne connaîs quasiment aucune entreprise ou le temps n'est pas une contrainte forte.

Et que penses tu du premier conseil pour gagner du temps qui est ... de prendre son temps, justement lorsque l'on développe quelque chose

Combien de fois ne t'es tu pas heurté à une impossibilité tout droit issue d'une décision inappropriée prise "pour gagner du temps", qui a eu pour effet de t'en faire perdre bien plus que ce que tu n'en a gagné par la suite

Personnellement, j'ai arrêté de les compter

C'est la ou la sécurité est aussi utile à la productivité. En Rust (je connais bien moins Swift) on peut utiliser les lambda sans risques. Au pire le compilateur te dira si ça pose le moindre problème de sécurité.

... A condition que le problème de sécurité que cela pose soit connu.

Car le véritable problème, ce ne sont pas les failles qui sont connues et malgré tout reproduites à l'envi. Ces failles, elles sont encore "relativement" faciles à repérer et à corriger quand elles surviennent.

Le véritable problème, ce sont toutes ces failles qui ne sont pas connues aujourd'hui, mais dont on se rendra compte de l'existence "demain". Ces failles, inconnues à ce jour, il n'y a absolument rien qui puisse t'en prémunir (forcément, vu qu'on n'en a pas encore connaissance), et elles peuvent rester présentes pendant des années avant que l'on ne s'en rende compte. Les exemples ne manquent pas pour nous en convaincre