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

Version imprimable

23/04/2019, 18h28
Bill Fassinou

1 pièce(s) jointe(s)

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.

Pièce jointe 469333
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 ?

:fleche: Êtes-vous du même avis qu'Alex Gaynor ? Pourquoi ?
:fleche: Avez-vous aussi été confronté à ces problèmes avec votre code ou dans du code legacy ?
:fleche: 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

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

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

:fleche: 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
24/04/2019, 00h33
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.

Citation:

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

Citation:

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…
24/04/2019, 01h34
Mingolito

Citation:

Envoyé par 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.

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 :ptdr:
24/04/2019, 02h35
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.
24/04/2019, 03h18
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

Citation:

Envoyé par lsbkf

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:

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.

24/04/2019, 03h48
lsbkf

Citation:

Envoyé par Bousk

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 !
24/04/2019, 04h03
jo_link_noir
Citation:

Envoyé par darklinux

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:

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.
24/04/2019, 08h06
ShigruM

Citation:

Envoyé par 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.

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.
24/04/2019, 08h19
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...
24/04/2019, 08h36
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.
24/04/2019, 09h50
AoCannaille

Citation:

Envoyé par Bill Fassinou

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?
24/04/2019, 11h30
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! 8O
Disons que le gars avait besoin d'étoffer un peu son blog ... :mouarf:
24/04/2019, 12h09
stardeath

Citation:

Envoyé par 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.

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.
24/04/2019, 13h30
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.
24/04/2019, 14h08
Bousk

Citation:

Envoyé par jo_link_noir

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...
24/04/2019, 14h09
abriotde

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.
24/04/2019, 16h42
emixam16

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!
24/04/2019, 17h24
jo_link_noir

Citation:

Envoyé par Bousk

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.
24/04/2019, 17h39
archqt

Citation:

Envoyé par AoCannaille

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.
24/04/2019, 19h30
Uther

Citation:

Envoyé par lsbkf

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.

Citation:

Envoyé par lsbkf

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.

Citation:

Envoyé par lsbkf

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

Citation:

Envoyé par 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...

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.

Citation:

Envoyé par 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

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

Citation:

Envoyé par wolinn

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.

Citation:

Envoyé par wolinn

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

Citation:

Envoyé par 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.

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.

Citation:

Envoyé par Bousk

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.
24/04/2019, 21h25
AoCannaille

Citation:

Envoyé par archqt

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.

Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)
24/04/2019, 22h30
koala01
Salut,

Citation:

Envoyé par Uther

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:

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:

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

Citation:

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 :question:

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

Citation:

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

Citation:

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!

Citation:

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 :question:

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

Citation:

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

Citation:

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 :question:

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 :question:

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

Citation:

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 ;)
24/04/2019, 23h00
stardeath

Citation:

Envoyé par koala01

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!

du fait qu'un humain est faillible, on créé des outils pour justement tenter de juguler le coté aléatoire de la défaillance humaine.
peu importe le niveau de compétence de quiconque, un outil sera toujours plus performant pour effectuer une vérification d'un pattern qu'on aura jugé incorrect.

Citation:

Envoyé par koala01

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 :question:

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

d'où le fait d'utiliser un outil qui coupera le saucisson à ta place, une meilleure qualité de découpe, une plus grande rapidité etc. etc. et on laisse le cuisinier faire des choses pour lesquelles une machine est encore inadéquate. (enfin si la chose qu'on veut est une amélioration de la qualité globale d'un code, sinon, pas d'outils, pas de guidelines, etc. et dans 2 mois on a un code que personne comprend...)

Citation:

Envoyé par koala01

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!

plus le "couteau" sera avancé, moins tu auras de chance de te couper un doigt.

Citation:

Envoyé par koala01

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 on va par là, pourquoi faire du c++, retournons à l'assembleur.

Citation:

Envoyé par koala01

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

pareil que précédemment, je me demande pourquoi on s'amuse à améliorer les choses, je devrais couper mon saucisson au silex, là j'aurais des sensations pures...

bref, il y a tellement à dire, je sais pas si c'est une bonne chose.
25/04/2019, 03h09
Uther

Citation:

Envoyé par koala01

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

En effet c'est tout a fait safe :
- dans le premier cas tu fais la même chose qu'avec un itérateur. Les langages "safe" font eux aussi ça sans contrôle de dépassement.
- dans le second cas tu fais le contrôle de dépassement manuellement.
Au final tu fais la même chose qu'un langage safe, avec plus de code et sans la garantie que ta règle sera bien respectée partout.

Citation:

Envoyé par koala01

Heu... tu veux parler de la fonction membre at() de std::vector :question:
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 ;)

Sauf que c'est encore partir du principe que les développeurs sont parfait et ne laissent jamais passer un bug en production. La pratique a prouvé maintes et maintes fois que c'est faux. Et une erreur de mémoire pouvant se transformer en faille de sécurité, avoir la possibilité de lever une exception pour empêcher un comportement potentiellement dangereux en production fait tout à fait sens.

Citation:

Envoyé par koala01

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.

Est-ce que le fait de dire "on vous avais prévenu" est suffisant sachant que l'on sait que l'humain est faillible ?
Dans certains cas peut-être. Quand on vise une certaine de sécurité on veut avoir des garanties, pas uniquement des responsables a blâmer en cas d'erreur.

Citation:

Envoyé par koala01

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!

Heu désolé, mais j'accroche pas du tout au raisonnement dans ce sens. Tu as essayé d'allumer un incendie avec un briquet seul ? A moins de faire exprès, c'est pas si facile que ça, alors qu'avec un lance flamme c'est de ne pas provoquer un incendie qui est difficile.

Donc oui, même si j'ai un lance-flamme a disposition, je vais demander a mon voisin s'il a un briquet pour allumer ma cigarette. Et même si j'ai un langage qui fait le boulot, je ne m'interdit clairement pas de regarder si il y en a un qui peut faire la même chose avec moins de risques.

Citation:

Envoyé par koala01

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!

C'est un outil, mais tous les outils ne se valent pas. Si on a un outil qui permet de faire la tache de manière de manière plus sure, il n'y a pas de raison de le mépriser.

Citation:

Envoyé par koala01

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 :question:
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!

J'ai croisé pas mal de vieux menuisiers qui avaient perdu des doigts à la scie circulaire. C'est beaucoup plus rare chez les jeunes artisans depuis que l'on a installé des gardes lames sur les scies circulaires.
Le responsable de l'erreur est clairement l’utilisateur de l’outil, mais une fois que tu as désigné ton coupable, ton problème est toujours là.

Citation:

Envoyé par koala01

Faut il te faire remarquer que même les programmes codés en Rust (je pense notamment à 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é ?

Il y a certes quelques parties de code en Rust qui ont été introduite dans Gecko ces dernières années, mais il est toujours très majoritairement codé en C++.
Mais c'est vrai qu'il serait intéressant de comparer le nombre de failles reportées par langage dans Gecko. Cependant, l'introduction de Rust dans le moteur étant plutôt récente, donc je suis pas certain que la quantité et l'historique soient suffisants pour que les chiffres soient représentatif.

Rust prétend empêcher totalement certains types d'erreur (hors code "unsafe") comme les erreurs mémoire ou les data races et fournit beaucoup de comportement par défaut qui limitent les risques, mais il ne prétends pas éliminer tous les risques de faille.

Citation:

Envoyé par koala01

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

La encore c'est un raisonnement en tout ou rien. Ce n'est pas parce qu'une technologie ne résout pas tous les problèmes du monde qu'elle n'est pas intéressante.

Citation:

Envoyé par koala01

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 :question:

Je dirais que c'est un bon conseil, mais que dans la pratique on a jamais le temps de tout faire parfaitement et qu'il y aura forcément a un moment un arbitrage entre le niveau de qualité attendu et le temps a allouer. Et si un langage peut faire gagner du temps en garantissant que certains type d'erreurs sont impossibles, ce temps peut être utilisé pour améliorer la sécurité sur d'autre points.
25/04/2019, 10h27
AoCannaille

Citation:

Envoyé par Uther

Donc oui, même si j'ai un lance-flamme a disposition, je vais demander a mon voisin s'il a un briquet pour allumer ma cigarette. Et même si j'ai un langage qui fait le boulot, je ne m'interdit clairement pas de regarder si il y en a un qui peut faire la même chose avec moins de risques.

Merci pour ta contribution pertinente (et celles des autres aussi!)

Je reviens juste sur ce point de ton argumentation.

Si on considére que l'humain est faillible, les outils (ie les nouveaux langages) le sont aussi, donc le nouveau langage à des failles, peut être pas aux même endroits.

Dans le cas que tu décris, est-ce qu'il ne vaut mieux pas se perfectionner sur un langage, connaitre toutes ses failles et donc savoir les éviter (dans l'idéal); quitte à passer par des normes de programmation, des outils et autres investissements temporels rentable dans le cadre d'un perfectionnement sur une carrière plutôt que de sauter sur un nouveau langage dont une courte veille techno démontre qu'effectivement, les risques identifiés sont gérés par le langage et pour lequel d'autres risques non identifiés surviendront au cours du développement et qu'en tant que non-expert tu ne seras pas capable de repérer à ce moment?
25/04/2019, 10h54
Pyramidev

Rappel important à propos du Rust :

En Rust, il y a un ensemble de règles strictes contrôlées à la compilations qui garantissent que le code n'a pas d'erreurs de mémoire.
Dans les cas où ces règles sont trop strictes et où on veut passer outre, on utilise le mot-clef unsafe.
Du coup, on a une vision claire sur les zone de code pour lesquelles on a la garantie qu'il n'y a pas d'erreurs de mémoire et celles où il faut faire attention.

C'est beaucoup plus sécurisé que d'écrire du code C++ sans contraintes et d'exécuter des outils d'analyse de code qui se débrouillent comme ils peuvent.
25/04/2019, 11h24
koala01

Citation:

Envoyé par stardeath

du fait qu'un humain est faillible, on créé des outils pour justement tenter de juguler le coté aléatoire de la défaillance humaine.
peu importe le niveau de compétence de quiconque, un outil sera toujours plus performant pour effectuer une vérification d'un pattern qu'on aura jugé incorrect.

Je ne disconviens absolument pas de la performance des outils. Je dis juste que, plutôt que de se reposer exclusivement sur cette performance, il serait bon que les gens pensent aussi à utiliser ce qui leur sert de cerveau, car, tant qu'ils ne le feront pas, les outils pourront être aussi performants que l'on veut, le risque restera identique.

Citation:

d'où le fait d'utiliser un outil qui coupera le saucisson à ta place, une meilleure qualité de découpe, une plus grande rapidité etc. etc. et on laisse le cuisinier faire des choses pour lesquelles une machine est encore inadéquate. (enfin si la chose qu'on veut est une amélioration de la qualité globale d'un code, sinon, pas d'outils, pas de guidelines, etc. et dans 2 mois on a un code que personne comprend...)

plus le "couteau" sera avancé, moins tu auras de chance de te couper un doigt.

Je me sens obligé de te contredire sur ce point.
Voici trois exemples qui te démontreront sans problème que tu fais une très lourde erreur en croyant que tu as moins de risques d'accident, même si on s'éloigne un peu des couteaux:

1- Une personne de mes connaissances était occupée à couper des planches avec une scie circulaire. A un moment, elle s'étonne que les dernières planches coupées aient toute une trace rouge qui n'a rien à faire là... jusqu'au moment où elle se rend compte que la dernière phalange de son majeur traine dans la sciure.

Elle ne l'avait pas senti (la coupe avait été trop nette et trop rapide), mais elle y avait perdu son doigt.

2- Il manquait à un de mes profs de menuiserie la dernière phalange de trois doigts, et il ne disposait encore de la "pince" que parce qu'on lui avait greffé le gros orteil à la place du pouce.

Ce prof était occupé à passer le plateau d'une table rond à la toupie, afin de faire une jolie moulure dessus, lorsque le sens du bois s'est -- forcément -- inversé, et que la lame de la touipe s'est "coincée" dans le bois, faisant valser la pièce.

Dans une telle situation, deux réflexes sont possibles : le bon, qui consiste à "tout lâcher", et à laisser la pièce de bois partir à sa guise, et le mauvais, qui consiste à essayer de la retenir. Il avait eu le mauvais, et sa main est donc passée dans les lames de la toupie, qui n'a pas fait la différence d'avec un morceau de bois.

3- Un boucher de mes connaissance était occupé à trancher du saucisson sur sa trancheuse. Comme la taille restante du saucisson était encore assez importante que pour en tirer plusieurs tranche, mais qu'elle était malgré tout "trop petite" que pour utiliser la pièce qui est sensée être utilisée pour pousser la charcuterie contre la trancheuse, il poussait son saucisson à la main. Son pouce était "juste un peu trop" en avant sur le saucisson, et il est passé dans la trancheuse.

Son pouce est désormais beaucoup plus petit que ce qu'il n'était juste avant cet épisode.

J'ai beau chercher, je peux te garantir que personne n'a perdu la moindre phalange, le moindre morceau de doigt, avec un simple rabot à moulurer, avec une simple scie à main, le moindre couteau, à moins que cela n'ait été purement volontaire (et très douloureux) ;) . Par contre, je peux aussi te garantir que de très nombreux menuisiers (pour ne parler que du métier que je connais) qui ont perdu une ou plusieurs phalanges dans les machines qu'ils utilisaient.

Malgré toutes les sécurités que l'on peut mettre aux différents outils, la conclusions est sans appel :

Bien que les outils "évolués" présentent de nombreux avantages, en terme de vitesse, de régularité et de précision sur les outils "basiques", leur utilisation est beaucoup plus risquée, aussi bien en termes de risques qu'en termes de conséquences.

Citation:

si on va par là, pourquoi faire du c++, retournons à l'assembleur.

Non, parce qu'il y a quand même un aspect essentiel, commun à l'ensemble des langages dits "de troisième génération" : il permettent un niveau d'abstraction bien plus important, et absolument indispensable à l'obtention des résultats que l'on attend de la part de l'ordinateur.

Citation:

pareil que précédemment, je me demande pourquoi on s'amuse à améliorer les choses, je devrais couper mon saucisson au silex, là j'aurais des sensations pures...

Il faudrait déjà que tu trouves encore un couteau en silex :D

Plus sérieusement, si tu as le choix entre un couteau en bronze (à condition d'en trouver un), un couteau en acier, un en inox et un en céramique. Je comprend que tu sois tenté de prendre celui en céramique. Mais tu devrais quand même te poser la question de savoir si tu en as absolument besoin. Un "simple" couteau en inox (vu que c'est ce qu'on trouve le plus fréquemment de nos jours) ne te suffirait il pas :question: Crois tu vraiment que tu fera des tranches plus fines ou plus égales avec le couteau en céramique :question:

Permets moi très sincèrement d'en douter, car la finesse et la régularité des tranches dépendront d'abord et avant tout de ton aptitude à faire des tranches fines et régulières. Tu pourras avoir le meilleur couteau du monde, si tu n'est pas capable de t'en servir correctement, tu n'obtiendras pas un meilleur résultat qu'avec un couteau "un peu moins bon" ;)
25/04/2019, 11h31
Uther

Techniquement, je n'ai pas entendu parler de beaucoup de risques de sécurité dans un langage "sur" qui n'existe pas en C++.
J'ai une impression que tu as une vision très orientée C++ de la sécurisation apportée par le langage. Dans C++, la sécurisation a été apportée principalement en rajoutant des objets sécurisés par dessus une base qui n'est pas sure, ce qui fait que si les objets sont mal utilisés, il peut rester des failles.

Je vais parler pour Rust qui est le cas que je connais le mieux. Il y a aussi des objets qui aident à la gestion mémoire, mais ils reposent sur un langage qui garantit quelles variables ont accès à quelle partie de la mémoire. Si ces objets sont mal utilisés, on aura une erreur de compilation, pas une faille discrète. La mauvaise connaissance de Rust va en effet compliquer la tache du programmeur qui va avoir beaucoup d'erreurs énervantes, mais le risque d'avoir une erreur technique que C++ aurait évité me parait bien faible. Après il restera toujours les erreurs logiques mais il n'y a pas plus ni moins de raison de les commettre en Rust qu'en C++.

Décider du jour au lendemain de réécrire tout son code dans un nouveau langage qu'on ne maitrise pas n'est certainement pas une bonne idée. La quantité de travail nécessaire est potentiellement énorme et n'en vaut peut-être pas la peine au vu des contrainte du projet. Mais considérer un langage plus sur pour un nouveau projet ou une réécriture nécessaire d'une partie d'un projet C++ peut tout a fait se justifier.

Enfin apprendre un langage supplémentaire, particulièrement le Rust qui oblige a bien réfléchir a la façon dont on utilise la mémoire, ne vous rend pas moins bon a utiliser un langage que vous connaissez déjà, bien au contraire.
25/04/2019, 17h59
archqt

Citation:

Envoyé par AoCannaille

Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)

Bien sûr, sauf qu'avec "l'obligation" d'utiliser des pointeurs nus en C, cela facilite l'arrivée de failles. Ce sera plus difficile d'avoir cela en C++ (si on évite les pointeurs nus).
Idem pour les débordements de buffers, en passant par la STL ce sont des problèmes connus et gérés....
26/04/2019, 10h14
Andarus

Citation:

Envoyé par Uther

Je vais parler pour Rust qui est le cas que je connais le mieux. Il y a aussi des objets qui aident à la gestion mémoire, mais ils reposent sur un langage qui garantit quelles variables ont accès à quelle partie de la mémoire. Si ces objets sont mal utilisés, on aura une erreur de compilation, pas une faille discrète.

ça marche comment sans ajouter aucune instruction à l’exécution j'ai du mal à comprendre?
26/04/2019, 14h32
Pyramidev
Citation:

Envoyé par Andarus

ça marche comment sans ajouter aucune instruction à l’exécution j'ai du mal à comprendre?

Par exemple, Rust pousse l'idée du RAII jusqu'au bout. En C++, si on lit une variable non initialisée, on a un comportement indéterminé. On peut aussi avoir un comportement indéterminé si on lit un objet dans un moved-from state (quoique ça dépend du type). En Rust, par contre, ce genre d'erreur entraîne une erreur de compilation, car les durées de vies sont plus strictes.

Un autre exemple en C++ est celui où on appelle std::string::c_str() et stocke le résultat dans une variable (appelons-là ptr). Plus tard, si on modifie la chaîne (par exemple avec std::string::append), l'implémentation peut avoir besoin de déplacer la chaîne ailleurs en mémoire. ptr devient alors un dandling pointer et représente une source de danger.
En Rust, par contre, pour toute variable muable, si on garde une référence dessus capable de modifier cette variable, alors cette référence doit être unique, tant qu'elle est accessible. Donc on ne peut pas appeler l'équivalent de std::string::append tant que la chaîne est déjà accessible ailleurs (via ptr). Pour que ça compile, il faut d'abord que ptr ne soit plus accessible. On peut alors appeler l'équivalent de std::string::append. Ce genre de contrôle se fait aussi à la compilation.

Il y a encore d'autres contrôles. Pour plus de détails, je conseille les chapitres suivants de The Rust Programming Language :
27/04/2019, 06h49
jimounette

moi jai ma theorie qui ne tient qu'a moi

au moins tu depends du systeme dexploitation
au moins c chiant a deployer au plus c'est long a développer

maintenant pour faire un simple hello faut avoir la derniere version de dll truc muche :p

deuxieme coup de gueule on apprend plus au dev pour la base de données de nommé correctement leurs tables
c'est pourtant simple
exemple VST_NOM = voiture nom en stock
non eux ils vont mettre ca en stock alors que stock existe pour pieces détachées

rien ne vaut la methode a lancienne, quitte a faire plus ligne de code, et ca peu depend le langage, c'est surtout comment on te lapprend desfois c'est dur a récupérer :p
27/04/2019, 11h15
yvslms

A chaque langage son usage.
La question n'est pas d'être sauvé ou non par un C++ dit moderne, mais d'être sauvé par le langage qui correspond à ses besoins.
Le C++ a fait ses preuves depuis longtemps dans des domaines et contextes bien précis qui ne sont pas comparables avec ceux d'autres langages.
On constate par contre une multiplication des langages à des fins surtout commerciales sans qu'il y ait d'innovations vraiment significatives.
27/04/2019, 22h33
Invité

Citation:

Envoyé par Pyramidev

Un autre exemple en C++ est celui où on appelle std::string::c_str() et stocke le résultat dans une variable (appelons-là ptr). Plus tard, si on modifie la chaîne (par exemple avec std::string::append), l'implémentation peut avoir besoin de déplacer la chaîne ailleurs en mémoire. ptr devient alors un dandling pointer et représente une source de danger.
En Rust, par contre, pour toute variable muable, si on garde une référence dessus capable de modifier cette variable, alors cette référence doit être unique, tant qu'elle est accessible. Donc on ne peut pas appeler l'équivalent de std::string::append tant que la chaîne est déjà accessible ailleurs (via ptr). Pour que ça compile, il faut d'abord que ptr ne soit plus accessible. On peut alors appeler l'équivalent de std::string::append. Ce genre de contrôle se fait aussi à la compilation.

Je suis complètement d'accord sur le fait que Rust apporte des fonctionnalités très intéressantes concernant la gestion mémoire. Par contre, je trouve cet exemple assez mal choisi : c_str n'est pas du C++ moderne ni même du C++. Pour moi, ça fait partie de la couche de compatibilité C bas-niveau telle qu'on pourrait l'avoir dans un bloc unsafe de Rust, où justement les avantages de Rust ne s'appliquent pas vraiment.

Hello, je me suis inscrit juste pour répondre à ce message.

A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.
Code:

1 2 3 4 5 6 7 8 9 10 #if _DEBUG #define _CRTDBG_MAP_ALLOC #include <crtdbg.h> #ifdef _DEBUG #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #else #define DBG_NEW new #endif
Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.
Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.

A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.
Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser. Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne. Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java. Ce qui n'est plus possible avec du C++ moderne, selon moi. Même pour un programmeur C ca va devenir compliqué.

Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions. Je trouve qu'il ajoute de la complexité à la complexité. Sans parler des messages d'erreurs qui font 3 pages. J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité, des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib, des property comme le C# et pourquoi pas une lib graphique plutôt que de charger la lib de notions de plus en plus techniques. Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.

Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C. Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?

Bonne programmation à tous
Cordialement,

Citation:

Envoyé par yrazet

Hello, je me suis inscrit juste pour répondre à ce message.

Bienvenue sur le forum ;)
Citation:
A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.
Code:

1 2 3 4 5 6 7 8 9 10 #if _DEBUG #define _CRTDBG_MAP_ALLOC #include <crtdbg.h> #ifdef _DEBUG #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #else #define DBG_NEW new #endif
On l'a tous fait au moins une fois :D

Mais, pour être honnête, il y a "à boire et à manger" dans la pratique...

Il y a, en effet, d'énormes avantages à utiliser un tel système (ne serait-ce que le fait que l'on puisse suivre les allocations de mémoire), mais il y a d'énormes inconvénients, qui découlent tous d'un fait tout bête : tu utilises une fonction qui t'est propre (DBG_NEW), ce qui implique:
que les allocations "tièrces" (comprends : exécutée en dehors de ton projet) ne sont pas prises en compte
qu'il est impossible, même si ton projet est correctement "saucissonné", de ne récupérer qu'une seule classe, une seule paire de fichiers d'en-tête (*.h / *.hpp) et d'implémentation (*.cpp) pour "autre chose" sans soit avoir besoin d'y ajouter <crtdb.h> (quid si un autre système similaire existe déjà dans l'autre projet :question:) ou sans avoir besoin d'en modifier le code pour pouvoir l'utiliser

Ce n'est -- bien sur -- absolument pas catastrophique, mais, disons que cela présente malgré tout un frein de taille à la réutilisation potentielle de ton code ;)

Citation:

Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.

Tu as raison, mais le fait est que, de toutes façons, le couple std::shared_ptr et std::weak_ptr ne devrait pas être ton choix "par défaut".

"Par défaut" (comprends: si tu n'as aucune raison de faire autrement), le meilleur choix de pointeur intelligent est d'utiilser std::unique_ptr, ne serait-ce que pour ne pas avoir à payer le coût d'un comptage de référence qui s'avère bien souvent inutile ;)

En outre, "la logique" voudrait que l'on n'utilise l'allocation dynamique que pour les classes dites "à sémantique d'entité", étant donné que l'on dispose déjà de deux classes (std::vector et std::array) pour représenter la notion de "tableaux", et que ces deux classes fournissent (lorsqu'elles sont correctement utilisées, cela va de soi) toutes les garanties nécessaires.

Citation:

Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.

Tu as raison sur ce point de vue.

Malheureusement, les choses ne sont pas aussi simples que cela, pour une simple et bonne raison : C++ est un langage à exception.

Un code aussi simple

Code:

std::cout<<"hello world";

pouvant parfaitemet lancer une exception, il est très difficile de prévoir tous les chemins d'exécution qui pourraient nécessiter la libération d'une ressource allouée de manière dynamique.

C'est la raison de la mise en place de ce que l'on appelle des "capsules RAII" (dans la catégorie desquelles on trouve std::unique_ptr et std::shared_ptr): ce sont des données qui se trouvent -- a priori -- sur la pile, qui sont donc automatiquement détruite lorsque l'on sort de la portée dans laquelle elles ont déclarées (comme n'importe quelle donnée sur la pile), et provoquent donc automatiquement la libération de la ressource allouée de manière dynamique.

Citation:

A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.

A l'exception des pointeurs intelligents, dont on vient de parler, c'est une approche que l'on peut comprendre, mais qu'on ne va sans doute pas plébiciter :aie:

La plupart des fonctionnalités apportées par C++11 et ultérieures permettent en effet de rendre le code plus sur (là où il y avait un manque flagrant de sécurité) et au compilateur de générer du code plus rapide.

La déclaration des fonctions membre comme étant delete, par exemple, nous permet d'écrire un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 class MyEntity{ public: /* une classe ayant sémantique d'entité ne peut être ni copiée ni assignée */ MyEntity(MyEntity const &) = delete; MyEntity& operator=(MyEnity const &) = delete; /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit * protected et non virtuel */ virtual ~MyEntity() /* = default */; };
là où il aurait fallu attendre l'édition de liens pour se rendre compte d'un éventuel problème avec un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 /* Avant C++11, on aurait travaillé de la sorte */ class MyEntity{ public: /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit * protected et non virtuel */ virtual ~MyEntity() private: /* on aurait déclaré le constructeur de copie et l'opérateur d'affectation * dans l'accessibilité privée, et ON NE LES AURAIT SURTOUT PAS * IMPLEMENTES */ MyEntity(MyEntity const &); MyEntity & operator=(MyEntity const &); }
Pire encore, si, par distraction, le développeur de MyEntity venait à fournir une implémentation du constructeur de copie et / ou de l'opérateur d'affectation, cela aurait pu occasionner quelques bugs très spécifiques ;)

De même, les mots clé override et final obligent le compilateur à s'assurer que les fonctions pour lesquelles ont redéfini le comportement existent bel et bien dans la classe de base, et qu'elles sont bel et bien virtuelles.

Il suffit de "si peu" (une étoile ou une esperluette en plus ou en moins pour le type de retour ou pour la déclaration d'un paramètre, par exemple) pour que l'on assiste à une surcharge de la fonction (qui n'est pas virtuelle) au lieu d'assister à une redéfinition de la fonction virtuelle que ce serait vraiment très dommage de ne pas forcer le compilateur à faire cette vérification ;)

Citation:

Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser.

Là encore, c'est une approche que l'on peut comprendre...

Après tout, nous nous en sommes passé pendant 13 ans, en créant au besoin un foncteur spécifique à l'intérieur d'une fonction hein :question:

Cependant, le système avait malgré tout ses limites... Et ce sont ces limites qui ont été repoussées grâce aux expressions lambda ;)

Il est -- encore une fois -- dommage que tu restes "bloqué" par des limites qui ont pu être abolies par la nouvelle norme ;)

Citation:

Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne.

Ca, c'est sans doute le plus gros problème!!!

Le C with classes n'a été développé à la base que pour servir de "fondation" au C++, parce qu'il fallait bien avoir "quelque chose" qui soit susceptible d'être compris par un compilateur C pour pouvoir générer le compilateur C++.

Mais, dés le départ, C et C++ ont été des langages différents, même si les premiers utilisateurs de C++ n'en avaient pas forcément conscience. Et, même si C++ a tout fait (du moins, au début) pour assurer une "certaine compatibilité" avec le C, la différence entre les deux langages n'a pu que s'amplifier avec le temps ;)

Citation:

Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java.

Et tu as encore une fois bien raison!

Seulement, la manière dont tu t'y prend n'est peut-être pas la bonne ;)

Citation:

Ce qui n'est plus possible avec du C++ moderne, selon moi.

C'est là que tu te trompe ;)

Les expression lambda (par exemple) sont apparues en 2006 en java. Tu ne dois donc pas avoir peur qu'un développeur java ne comprenne pas une expression proche de

Code:

[](Type t)->bool{/* ce qu'il faut faire */};

, même s'il y a une paire de crochets en plus ;)

Citation:

Même pour un programmeur C ca va devenir compliqué.

Ah oui, en C, les expressions lambda n'existent à mon sens pas encore ;)

Mais C++ est beaucoup plus proche (malgré toutes les différences qu'il a par rapport à java) de java que de C, contrairement à ce que l'on croit ;)

Citation:

Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions.

Chaqun verra midi à sa porte ;)

Citation:

Je trouve qu'il ajoute de la complexité à la complexité.

Au contraire, je te dirais bien que les versions de C++ d'après 2011 font tout pour essayer de supprimer une partie de la complexité, ou, du moins, pour arriver à en cacher une grosse partie ;)

Citation:

Sans parler des messages d'erreurs qui font 3 pages.

Les messages d'erreurs qui font trois pages ont toujours été dus à l'approche générique du C++. Enfin, je vais préciser:

Quand une seule erreur provoque un message d'erreur de trois pages, tu dois t'attendre à ce que ce soit du à une erreur en programmation générique.

Que tu aies 120 "faux positifs" après la seule erreur réelle de ton code, parce que le compilateur a "perdu les pédales" mais qu'il a malgré tout essayé de terminer le traitement de ton fichier d'implémentation, ca ca a toujours été ;)

Mais même là, les nouvelles fonctionnalités tendent de résoudre le problème (je pense, entre autres, au static_assert) en faisant apparaitre en priorité un message plus clair et plus précis ;).

Citation:

J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité,

Je suis mal réveillé, je ne vois pas trop de quoi tu parles...

Citation:

des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib,

Cela existe depuis toujours, même si ce n'est pas très utilisé

Citation:

des property comme le C#

Quoi :question: des get et des set automatiques :question: Quelle horreur !!!!

Citation:

et pourquoi pas une lib graphique

Figure toi qu'il semblerait que ce soit en cours

Citation:

plutôt que de charger la lib de notions de plus en plus techniques.

La seule notion spécifique à la bibliothèque qui ait été rajoutée (en dehors de certaines classes dont on avait un réel besoin, comme les thread, la gestion du temps ou l'alléatoire), ca a été la sémantique de déplacement.

Et même la sémantique de déplacement représentait un besoin vraiment réel en termes de performances ;)

Citation:

Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.

Encore une fois, chacun verra midi à sa porte, mais LPCSTR

c'est du C
c'est absolument non portable

Dans un monde où windows n'est clairement plus le seul système d'exploitation utilisé, le deuxième point est particulièrement dommage ;)

Au passage, pourquoi ne pas te tourner vers Qt, si tu fait des applications graphiques :question: Il te suffirait d'avoir un compilateur croisé pour que tes applications fonctionnent également sous linux et ou sous mac... cela ne t'intéresse pas :question:

Citation:

Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C.

Et tu te retrouveras avec un tas de problèmes encore bien pire que ceux auxquels tu es confronté avec java ou avec C++ :aie:

C a l'énorme avantage d'être la "franqua lingua" du développement. Mais, si tu a l'habitude du C#, ce n'est vraiment pas pareil ;)

Citation:

Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?

Et pourtant, tu choisirais le seul langage qui ne propose à la base ni classes ni espaces de noms :aie:

Citation:

Bonne programmation à tous
Cordialement,

Pareillement ;)

30/04/2019, 21h39
Seabirds

C'est marrant, maintenant que je vous ai lu je ne peux pas m’empêcher de m'imaginer avec les 20 doigts en moins tronçonnés par une mauvaise utilisation de la sémantique de déplacement, et des phalanges sanguinolentes qui traînent un peu partout dans une mémoire encombrées par des tranches de saucissons desséchées et des tartines de lambdas, au milieu des miettes d'un chronomètre atomisé par une mécompréhension de la STL.
Pour autant, je peux pas m’empêcher de penser que c'est juste une phase d'adolescence programmée, et que quand je serai grand ...