Uther a écrit :



Au risque de me répéter. Non, non et re non. Tu réduis le problème de la sécurité mémoire au contrôle de dépassement, c’est bien plus que cela.

Le dépassement de tampon n’est qu’un des problèmes de sécurité mémoires. D’autre problèmes comme la double libération ou l’utilisation après libération sont au moins aussi importants.



L’élément de la sécurité mémoire qui pose le plus de problème au utilisateurs de C/C++, ce n’est absolument pas les contrôles de dépassement, mais les mécanismes de gestion de la mémoire imposés.  Leur principal problème avec les langages managés, c’est qu’ils imposent généralement des systèmes qui échappent à leur contrôle comme un GC traçant, ce qui a de gros impacts sur les performances et la consommation des ressources.



    Le gros avantage de Rust par rapport aux autres langages memory safe, c’est qu’il n’est pas “managé”. La gestion de la mémoire est totalement libre, il impose juste des règles vérifiées au moment de la compilation (que là encore on peu ignorer via bloc unsafe) pour garantir qu’on n’utilise jamais de la mémoire non encore allouée ou libérée.







La vérité, c’est qu’il n’existe pas de manière parfaitement idéale et unique de gérer la mémoire. Il existe différentes méthodes qui ont toutes leurs avantages et des inconvénients. Et donc qui conviennent plus ou moins bien suivant le contexte.



La encore, la philosophie de C/C++ n’est pas de vouloir proposer la meilleure méthode, mais de permettre la plus grande souplesse d’implémentation du gestionnaire mémoire de son choix.



En C/C++ il n’est pas rare qu’un programme optimisé embarque plusieurs gestionnaires mémoires différents en fonction de la stratégie la meilleure pour différents types d’objets.





Le dépassement de tampon n’est qu’un des problèmes de sécurité mémoires. D’autre problèmes comme la double libération ou l’utilisation après libération sont au moins aussi importants.





Ce ne sont pas des problèmes pour de vrais programmeurs C/C++ compétents.



D’abord, il y a d’excellents outils pour tracer facilement les problèmes d’allocations.



Mais surtout, il y a des stratégies de programmation qui permettent de les éviter d’emblée.



Exemple parmi d’autres :http://loic-joly.developpez.com/tutoriels/cpp/smart-pointers/



Mais aussi : WikipediaLe bound checking n’est certainement pas aussi coûteux que ça a mois que

tu fasses des calculs particuliers, dans ce cas il est facile de les

éviter localement sur les points chaud. L’expérience prouve que la la différence de vitesse entre du C++ bien écrit et

du Rust bien écrit est globalement négligeable, ce qui n’est pas le cas avec

les langages managés.





https://benchmarksgame.alioth.debian.org/u64q/rust.html





Si tu rajoutes le contrôle de dépassement au C tu obtiens le Checked C. qui est loin d’être aussi sûr que le Rust et qui n’offre aucune fonctionnalité de plus haut niveau.

Le Java ou le C# c’est bien plus que ça. Ils ajoutent énormément de fonctionnalités au prix d’une perte du contrôle de gestion mémoire.





Rust à peut être une belle carte à jouer face à Java ou C#.



En revanche, face à C/C++ je n’y crois pas. Trop de monde derrière le standard. Le langage évolue constamment. Il y a déjà eu de multiples tentatives…





On est d’accord que safe vs unsafe par défaut, c’est une philosophie différente, mais elle n’a que peut d’impact sur les performance finales.





Aller rencontrer des programmeurs C/C++ qui font du soft à haute performance. Vous comprendrez pourquoi vous ne leur vendrez jamais ce discours. Pour résumer rapidement, les cycles d’accès mémoire ne sont pas gratuit et il y a des cas de figure ou ça compte.



Sinon, c’est un très mauvais argument pour vendre Rust. Ca fait des années qu’il est utilisé par les fans de C# et même de Java. Personne ne l’écoutera.





La plupart des gens qui veulent du contrôle choisissent C++ non pas par choix mais par absence d’alternative.

Il faut voir que des langages qui offrent le contrôle complet du bas niveau mais qui

sont sûrs par défaut, ça court pas les rues. A la limite le Ada s’en

rapproche.





Ada n’a pas eu tellement de succès. Il a justement été victime du succès de C/C++…





Voila : le C++ est un langage parfaitement sur si on utilise des gens qui ne font pas d’erreur. Sauf que malheureusement ces gens la n’existent pas. Même les meilleurs programmeurs font des erreur de mémoire pour la bonne et simple raison que c’est facile d’en faire dans ce langage si on relâche son attention.





C’est une idée reçue.



En utilisant des classes validées pour la manipulation de la mémoire, la faute d’inattention provoquant une erreur de mémoire devient quasiment impossible, même en étant bourré.



Par ce moyen, il est possible d’écrire des milliers de lignes de code sans risquer le moindre problème.



Le problème de C/C++ n’est pas tellement le langage, mais le fait que beaucoup de jeunes programmeurs n’ont pas réellement appris comment l’utiliser correctement.



L’autre problème, c’est qu’il faut du temps pour se constituer une bibliothèque de qualité, mais c’est aussi une des raisons pour laquelle ses utilisateurs ne lâcheront pas facilement ce langage pour un autre.





Il faut comparer ce qui est comparable.Forcément, qu’on ne va pas avoir d’attaque par dépassement de tampon sur un site web vu que 99% des langages utilisés pour ça sont protégés contre ça.

 Je serais curieux de connaître les chiffres si ça n’était pas le cas.





Nous avons déjà la réponse…



Un serveur moyen, c’est des millions de lignes de code en C pour quelques milliers de lignes de PHP.



Comme par hasard, les attaques sont plutôt du coté de la minorité de code en PHP…





Par contre, au niveau des attaques sur les applications, l’erreur mémoire est toujours une valeur sure et elle est partie pour le rester un moment encore. On en trouve des dizaines par an sur tous les navigateurs et c’est pas comme si on découvraient le problème.



C’est beau de rêver. Tant qu’on introduira du nouveau code, on introduira de nouveaux bugs, d’autant plus si on a pas d’aide à les prévenir.





Les navigateurs sont un cas particulier. D’abord, ils sont par essence extrêmement exposés. Ensuite, le fait que leur code doit évoluer en permanence pour suivre l’évolution rapide des standard n’aide pas du tout à le stabiliser.



Le fait d’utiliser un langage sécurisé est un choix qui peut se tenir.



Mais une autre option est d’utiliser un style de programmation adapté.



Les deux solutions ont leurs avantages et inconvénients.





Justement Rust est issu d’un de ces effort de R&D fait par Mozilla pour apporter de la sécurité au code natif.

Contrairement à ce que tu crois Rust est bien un langage natif, performant qui permet de contrôler ce qui se passe à bas niveau et absolument pas managé comme comme le sont Java, C# ou même Go.





La solution du bound checking est plutôt une recette ancienne.



La R&D dont je parlait vise justement à améliorer la sécurité du code sans recourir au bound checking.



Ainsi, ces dernières années, on a vu des solutions comme le DEP ou ASLR, les protections de pile.



L’un des nouveaux axe vers lequel tends le développement, c’est d’isoler des portions de code grâce au matériel.





Les programmeurs ont principalement utilisés le C car parmi les langages qui offre un très bon contrôle de bas niveau (pointeurs, allocation mémoire manuelle, …), c’est le plus reconnu. Le C avec bound check n’existe justement pas, ce n’est pas pour rien si Microsoft est en train de le créer(Checked C)

 

La plupart des langages qui contrôlent les dépassement ne sont pas des langages de bas niveau.





Est ce réellement une bonne idée de multiplier les langages alors que ces fonctionnalités sont déjà possible en C++ compte tenue de l’énorme souplesse de ce langage ?





Le C avec bound check n’existe justement pas, ce n’est pas pour rien si Microsoft est en train de le créer





Si d’aventure cela avait le moindre succès, cela sera vraisemblablement repris dans l’évolution du standard C++.



Le C a survécu a travers les ages grâce à sa capacité d’évolution.





Tu pose ça en dilemme cornélien que le but de Rust est justement de ne pas tomber dans cette approche.

 L’intérêt de Rust est justement que pour atteindre la sécurité, il ne retire pas la gestion mémoire du contrôle de l’utilisateur, mais l’oblige a prêter attention a l’usage qu’il en fait.



Rust est à la fois plus sur que Java et C# et offre des performance comparables au C++.



Le point négatif de Rust se situerait plus sur un troisième axe décorrélé de ces deux qui serait la complexité, car l’utilisateur doit prouver au compilateur que son code est sur.

 



Malheureusement, c’est un point qui risque de ne pas plaire du tout aux programmeurs C/C++.



Les programmeurs C/C++ sont des programmeurs expérimentés qui s’agacent très rapidement quand il faut “négocier” avec un compilateur. C’est d’ailleurs une des raisons pour laquelle ils apprécient particulièrement ce langage.





Une dernière fois, Rust laisse tout le contrôle que l’on veut. Toutes ces “restrictions” peuvent être levées.

Le point important, c’est qu’on ne fait rien de “unsafe” sans s’en rendre compte alors qu’en C++, presque tout peut potentiellement partir en cacahuète, ce qui fait qu’au bout d’un moment même les meilleurs programmeurs (ce qui est déjà une denrée rare) se font avoir.





Pas d’accord.



C’était facile de faire de l’unsafe dans le C façon ancienne.



En C++, la bonne pratique pour sécuriser son code, c’est d’encapsuler tout ce qui est “unsafe” dans des fonctions qui vont pouvoir être manipulées ensuite de manière bien sécurisée. Dans ce cadre, les chance qu’un programmeur raisonnablement compétent écrive du code unsafe sont nulles.



Au passage, je n’ai encore jamais vu un code C/C++ partir en live dans les mains d’un programmeur compétent et dans un cadre de travail sérieux.



Dans les SS2I qui prennent les programmeurs pour du papier toilette, c’est une autre histoire. " />

cheme_ a écrit :



Je me suis mis sérieusement à rust depuis un peu plus d’une année, et le positionnement pris par rust est bien la niche C/C++, je dirais que rust se positionne plus au niveau du C (le modèle est déliberement simple pour permettre d’être à un niveau de perf le plus bas possible et n’avoir que des abstractions coût 0  et un minimum de surprises (un modèle objet n’est pas franchement envisagé)). Il suffit de jeter un coût d’œil aux api pour s’en persouader.

 

La transition vers rust est bien plus aisée pour des personnes venant du C ou ayant eu à faire à des problématiques bas niveau, la conception (et des limitations associés) du language pouvant paraitre assez obscure sinon.



Utiliser rust dans des cas d’utilisation similaire à java/c# serait une abération, autant faire du Go…







Point de vue intéressant et surtout défendu avec de bons arguments.



Reste que IMHO il y a quand même des différences philosophiques importantes entre les deux langages. Mais après tout, c’est aussi cette différence qui fait l’intérêt d’avoir des langages différents.



Si je le compare à Java ou C#, c’est parce que comme eux, Rust a fait le choix de sécuriser les accès mémoire. Mais il est clair que Rust adopte une partie de la philosophie du C/C++ et que c’est un gros avantage par rapport à Java et C#.



Maintenant, la question qu’il faut se poser, c’est pourquoi un programmeur voudrait utiliser C/C++ aujourd’hui. La réponse est bien souvent parce qu’on veut le maximum de performances.



Rust est peut être aujourd’hui le meilleur compromis entre les performances de C/C++ et la sécurité de C#. Je trouve cela indéniablement intéressant.



Mais la question qu’on peut se poser, c’est de savoir s’il vaut mieux le présenter comme un langage plus sécurisé que C/C++ ou comme un langage plus rapide que C#. Pour ma part, je préfère la deuxième solution.



Je précise que c’est un point de vue qui ne se base pas sur la technique, mais sur ce que j’estime être la meilleure stratégie de com.



Je pense que c’est une erreur de présenter la communication par rapport à C++. Parce qu’en procédant ainsi, le risque est de se confronter frontalement à cette partie de la communauté C/C++ qui est (1) obsédée par les performances, (2) extrêmement conservatrice, (3) très influente.

Uther a écrit :



Entierement d’accord! En bas niveau il est important de pouvoir gerer la memoire comme on le souhaite et c’est justement, ce qui fait un des interet de Rust par rapport aux langages managés. On est libre de gerer la mémoire comme on le souhaite.

Et on peut tout a fait avoir plusieurs allocateur de memoire differents.







Et bien c’est justement pour cela que je pense que Rust a une belle carte à jouer par rapport aux langages managés.



Il en a le principal avantage sans en avoir les inconvénients.





Bref tu viens de citer tous les avantages de Rust qui au lieu de rajouter plus ou moins bien ces concept par dessus le langage, les integre dans le langage en garantissant par defaut leur bon usage.





Paradoxalement, le fait que dans C/C++ beaucoup de choses soient implémentées “par dessus le langage” plutôt qu’“intégrées” c’est justement ce qui plait aux programmeurs et donne beaucoup de souplesse à ce langage.



Le fait de vouloir garantir le bon usage n’a jamais été une priorité en C/C++. L’esprit de ce langage, c’est justement “tu est compétent, tu est sensé savoir ce que tu fais”. Et certains programmeurs aiment cela.



On peut remarquer que la plupart des langages qui ont évolué à partir de C/C++ ont voulu proposer, soit des choses mieux intégrées, soit un meilleur encadrement pour éviter les bêtises. Ces langages ont trouvé leur marché, mais ils se sont éloignés de l’esprit de C/C++.





Si tu regardes le detail tu veras que Rust fait aussi bien voire mieux que C++ dans la plupart des tests. ceux dans lesquel il est derière, c’est lie au SIMD qui n’est pas encore bien supporté par Rust, mais il travaillent dessus.

Rien a voir avec les Bound Chech.





La question qu’on pourrait se poser, c’est pour quelle raison un langage comme Rust serait plus rapide que C/C++. Et cela d’autant que Rust utilise une partie de la chaine de compilation de LLVM. Ce n’est pas en ajoutant du Bound Checking (donc en ajoutant des instructions à exécuter) que l’on améliorer la vitesse d’un langage.



Effectivement, en regardant un peu le code, on s’aperçoit que ces benchmarks s’éloignent trop d’un test pur du langage donc reviennent à tester des fonctionnalités annexes (comme OpenMP).



Le problème, c’est qu’il n’y a pas énormément de tests de Rust. Et d’une manière generale, comparer les performances de deux langages demande d’y passer beaucoup de temps.



Par exemple, le C/C++ n’est pas qu’un langage orienté vers les performances. Parmi les dizaines d’options de compilation, certaines fonctionnalités de haut niveau ont un impact sur les performances. Il faut également bien savoir utiliser le langage lui même et le rôle de certains mots clés.





Pourtant ce n’est clairement pas le but de Rust de concurrencer Java et C#. C’est plutôt le domaire du Langage Go.





Que la communauté suggère des orientations plus pertinentes que le but que s’étaient fixé les créateurs, c’est une chose relativement courante.





Rust vise clairement les programmeurs qui veulent controler le bas niveau.





J’ai le sentiment que les créateurs de Rust n’ont pas vraiment mené de véritable étude de marché pour comprendre les domaines d’applications de C/C++.



Par exemple, dans l’embarqué avec des petits microcontrôleurs qui ne sont pas superscalaires, l’overhead du “bound checking” est bien plus élevé que sur des gros CPU.



Avec des architectures parfois bizarres, la souplesse d’adaptation du C est une grande force.





En C++ aussi, il faut verifier qu’on ne fait pas de depassement si on ne veut pas creer de bug. La seule difference c’est qu’il faut l’inserer manuelement, la ou en Rust il faut l’enlever s’il s’avere qu’il est inutile.

Bref la difference, c’est que si le programmeur fait mal son boulot en Rust on a un risque de perte de performance, alors qu’en C++, on a un risque de bug, voire de faille de securité.





C’est tout à fait cela.



Mais il existe des problématiques ou les performances sont primordiales et d’autres sur lesquels c’est la sécurité qui doit primer.



Et le bound checking systématique n’est pas pour autant impossible en C++. Rien n’empêche de créer une hierarchie d’objets qui dépendra d’une classe d’accès unique. On peut centraliser le bound checking de l’ensemble de l’application sur une seule ligne de code.



Une technique qui est souvent utilisée en C/C++ par les bons programmeurs, c’est d’utiliser la compilation conditionnelle pour truffer son code de vérifications de cohérence. Cela dépasse d’ailleurs le simple bound checking puisque l’on peut vérifier la cohérence des données et bien d’autres choses.



Une fois vérifié que le code tourne sans bug, on peut désactiver ces tests en basculant une simple option et rendre ainsi son programme plus performant.





Bref tout comme en Rust sauf que tout cela est bien integré au langage pour que leur utilidation soit la façon de faire par defaut et pas mis par dessus avec le risque d’oublier ou de mal les utiliser.





La voie de C/C++, c’est justement qu’on aime avoir une séparation entre le langage et les concepts. En fait, dans ce langage, il n’y a pas grand chose qui soit complètement intégré. Et c’est ce qui fait sa force.



Le risque d’oublier ou de mal utiliser ? Dans une grande équipe avec un turn over de fou, c’est possible.



Mais je n’ai jamais vu ce genre de souci avec une équipe de développement sérieuse et stable.





De plus, toi qui semble temps aimer les performance tu dois bien savoir qu’un smart pointer, n’est pas gratuit non plus : il a un coup en cycle. Le systeme de detection des lifetimes de Rust permet de garantir la securité sans surcout dans pas mal de cas sans utiliser de smart pointer.





Pas forcément. Ca dépends comment tu les implémentes.



Par exemple rien ne t’empêche de séparer la gestion de la durée de vie d’un objet de son pointeur d’usage.





En effet, mais pas que. Même les bons programmeurs ne sont pas infaillibles. Mozilla ne sont pas des debutants dans le domaine de la securite, pourtant ils ont senti le besoin de developper Rust.





Un navigateur Web est par nature une application extrêmement sensible en matière de sécurité. Les préoccupations de Mozilla sont donc assez compréhensibles.



Il faut comprendre que des programmeurs travaillant dans des domaines différents peuvent avoir des préoccupations complètement opposées.



Des avis opposés ne signifient pas forcément que quelqu’un a tort.





C’est difficilement comparable, on ne met pas les memes moyens de contole dans les deux cas. Si on elevait la securité web a PHP, je pense que ca serait encore pire.





Tout à fait.



Ce qui démontre que la sécurité apporté par le bound checking n’est qu’un élément parmi bien d’autres.





Et puis le PHP comme le C dans le domaine du bas niveau est lui aussi un langage pas pensé du tout a la base pour la securite web auquel on rajoute des framework par dessus pour essayer de limiter les risque





Ce que je voulais démontrer, c’est que le bound checking ne fait pas tout. On peut avoir des failles de sécurité énorme malgré l’usage d’un langage “memory safe”. Le fait de porter attention à la qualité du code apporte bien plus de sécurité que tout autre considérations.



Bien sûr, un logiciel critique en matière de sécurité peut vouloir mettre toutes les chances de son côté et combiner toutes les logiques possible pour y arriver. Mais il faut garder à l’esprit que toute spécialisation extrême se paye toujours d’une façon ou d’une autre par des inconvénients. On comprends aisément qu’une bonne Formule 1 ne pourra jamais être en même temps un bon véhicule de transport des marchandise.





Ils sont plus exposes certes mais ont aussi plus de moyens dedies.

La securite memoire ce n’est pas juste des risques de failles mais aussi des bugs pas evident a detecter. Bref c’est aussi potentielement du temps de dev gagne, ce qui peux interesser plus que les gens interessés par la securite





Il fut une époque lointaine ou les pointeurs fou étaient la bête noir de tout programmeur en C…



Mais aujourd’hui, il existe de très bons utilitaires qui permettent de détecter très facilement ces problèmes.





C’est toujours bon a prendre, maos ces solutions ne font que limiter le risque d’exploitation du bug mais ne les empechent pas.





Si on a des failles théoriques mais qu’au fond il est difficile d’en tirer quelque chose en pratique, ou est le problème ?





Le C est au contraire le modele du langage qui a très peu evolué, au vu de son grand age.





Pour avoir programmé en C il y a plusieurs décennies, le C/C++ moderne n’a plus grand chose à voir. A l’époque des compilateurs ne vérifiaient même pas les arguments d’un appel de fonction. Tu te trompait, ça plantait, voir pire.



Mais évidement, l’esprit du langage, lui n’a jamais changé…





Il a surtout reussi car il n’a pas trop eu de concurence en langages de bas niveau, ce qui lui a permi de devenir la reference.





C’est vrai. Et d’ailleurs on ne peut que regretter ce manque de concurrence.



Mais cela s’explique par le fait que si les nouveaux langages prétendant améliorer C n’ont pas manqué, ils n’ont jamais su conserver ce qui faisait l’esprit de C. Du coup, ce langage a toujours conservé son intérêt.



Rust semble s’en éloigner un peu moins que Java ou C#, mais il s’en éloigne quand même.



Je pense que le langage qui pourra prétendre à remplacer C/C++ n’est pas encore né.





Consulte les bulletins de securité des grands logiciels, tu veras que les failles liées a la memoire sont légion et se ne sont certainement pas des debutants.





Parce que la vérité, c’est que le fait de trouver de temps à autre un bug liée à la mémoire n’empêche personne de dormir.



Tous les logiciels n’ont pas non plus des implications fortes en terme de sécurité.

Uther a écrit :



En fait c’est aussi le cas en Rust, la plupart des mécanismes sont implémentés sous forme d’éléments de la  bibliothèque standard, mais il peuvent reposer sur les concepts de ownership et des lifetimes, qui leur permettent d’avoir des garanties sur l’utilisabilité ou non de certaines variables.







La question a propos de ces mécanismes, c’est de cerner a l’usage tout ce qu’ils impliquent dans un sens comme dans l’autre. Je pense qu’il faudra du temps.





C’est justement l’intérêt du Rust, il essaye d’apporter plus de sécurité tout en restant proche dans l’esprit du C++.





Tout à fait. Mais la question qu’il faut se poser est une pure problématique de marché : Ceux qui ont des vraies préoccupations en matière de sécurité sont t’ils encore très nombreux à programmer en C/C++ ?





Théoriquement le Rust ayant plus de certitudes sur la durée de vie des variables, il pourrait se permettre certaines optimisations que le C++ ne peut faire. Mais pour le moment ce n’est pas vraiment le cas.





C’est tout à fait véridique.



Plus un compilateur peut restreindre le champ des possibilités, plus il peut optimiser. C’est la raison pour laquelle des langages comme Javascript sont une véritable catastrophe. Ce que les jeunes programmeurs ne veulent pas comprendre.



Mais l’esprit de C/C++ c’est aussi d’éviter de tomber dans l’excès de rigorisme qui apporte inéluctablement des soucis majeurs, particulièrement quand on travaille à bas niveau. Ce juste milieu est aussi l’une des raisons majeures pour laquelle ce langage est apprécié.



Mais le C/C++ est un peu un langage à géométrie variable. Si l’on veut pousser l’optimisation, on peut utiliser des des mots clés et des “PRAGMA” pour affiner le comportement du compilateur par rapport à ses réglages par défaut, voir utiliser certaines spécificités du processeur. Le programmeur est laissé libre de les utiliser ou non. Exemple, pour optimiser le comportement du compilateur vis à vis du “pointer aliasing”, il y a un mot clé qui permet de l’informer qu’il n’y a pas de risque d’accès à la même case mémoire par un autre pointeur et que le compilateur peut différer les écritures si l’optimisation l’exige.





Rust s’appuyant sur LLVM,  les performances d’un code Rust ou C++ optimisé avec le même sérieux sont généralement équivalentes (à plus ou moins quelques pour-cents près dans un sens ou dans l’autre). L’exception étant le SIMD qui n’est pour le moment que partiellement géré par Rust.





Tout à fait. La prise en charge du SIMD arrivera certainement un jour. Ce n’est pas une limitation du langage.





L’impact du bound checking est, encore une fois, négligeable la plupart du temps.





Sur ce problème, mon opinion est qu’il ne faut pas raisonner par la généralité. Certains cas de figure ne présentent effectivement pas une différence perceptible. Dans d’autres, le surcoût peut représenter un facteur important.





Et facile a désactiver localement au points particuliers où il pourrait poser problème.





Certes.



Mais dans certains types de logiciels orientés performance, on pourrait perdre un temps certain à rechercher tout ces points. Sans compter de devoir se poser des questions pour tous les cas intermédiaires. C’est pourquoi dans certains domaines il est logique de préférer l’absence de bound checking par défaut.



Sans compter d’autres soucis, par exemple un bound checking sur l’ensemble du programme aboutit à un code plus volumineux (ça demande des instructions assembleur supplémentaires). Et les petits micro contrôleurs n’ont parfois que quelques milliers d’octets de mémoire. Déjà qu’en C j’ai connu des cas on ça passait vraiment tout juste…

 



Avec Go, le problème est assez différent : c’est surtout qu’il a été présenté comme un langage système et donc un concurrent de Rust qui a été présenté en même temps, parce qu’il compile en binaire en AOT .

 

Mais Go n’en est clairement pas n’en est pas un langage système, du moins pas dans le sens d’un langage avec lequel on peut programmer des briques élémentaires d’un système ( Kernel, Drivers, Barebone …). Les programme Go ont un runtime imposant qui gère notamment un ramasse-miette. Cela le rend inadapté à la programmation système car son comportement bas niveau difficilement prévisible et donc son intégration avec d’autres systèmes problématique.





Je suis totalement d’accord.



Mais Rust plaira t’il aux programmeurs système quand on sait que beaucoup ont déjà du mal avec C++ au motif qu’ils n’ont pas un contrôle aussi poussé qu’en C…





Rust a d’abord été fait pour les besoin de Mozilla, qui sont certes particuliers, mais pas marginaux non plus. Leur but n’est pas de signer l’arrêt de mort du C++ mais de fournir une alternative viable. Il y a plein de langages qui vivent très bien sans avoir les part de marché de Java ou de C.





Tout à fait.



Comme pour tout produit, l’enjeu est de toucher le public susceptible de manifester un intérêt. Et je pense qu’il n’est pas du tout certain que cela soit du côté des programmeurs C/C++ qu’il y ait le meilleur potentiel.



C’est d’autant plus vrai que la communauté C/C++ c’est un milieu extrêmement conservateur…





Bien que le langage soit prévu pour être utilisable sur les architecture modeste, il ne s’agit pas d’une priorité pour le moment peur i686, x86_64, ARMv7, ARMv8 et MIPS sont supportés.





C’est déjà pas mal pour le moment.



Le problème n’est pas tellement les architectures modestes, mais plutôt l’embarqué sur des petits microcontrôleurs. Les processeurs n’étant pas superscalaires, le bound check n’est pas à l’aise.

  



J’ai bien l’impression que tu as la chance de travailler dans un entreprise très sérieuse, avec une équipe parfaitement gérée et composée de développeurs quasi infaillibles. Mais, vraiment, la majorité des développeurs ne sont pas dans ce cas, et de mon expérience, faire du C++, ne rend pas systématiquement les gens plus intelligents.





Le domaine du logiciel est fait de secteurs d’activité très différents qui ont des problématiques complètement différentes en terme de qualité, rapidité de développement, sécurité.



La majorité des programmeurs en terme de nombre, c’est la SS2I qui produit des logiciels personnalisés courants. Cela fait bien longtemps qu’ils ont abandonné le C/C++ pour des raisons compréhensible. Dans cette activité, les performances ne sont pas une priorité. Ce qui compte, c’est surtout la rapidité de développement.



A l’opposé se trouve une des programmeurs qui font des logiciels à très haute performance. Ils sont moins nombreux mais leurs logiciels peuvent être utilisés par un très grand nombre de personnes. L’enjeu sur un noyau de qualité n’est pas le temps passé mais la qualité du résultat.



Entre les deux, on trouve les éditeurs de progiciels. Les priorités varient en fonction du secteur. Un jeu vidéo est plus orienté performances. Un logiciel de comptabilité doit faire preuve de stabilité. C’est un monde de besoins spécifiques. Mozilla est un bon exemple : Le navigateur a des besoins de sécurité très importants. Et ils doivent suivre des normes qui évoluent souvent.





de mon expérience, faire du C++, ne rend pas systématiquement les gens plus intelligents





Effectivement.



Les programmeurs qui se souviennent de l’époque ou C/C++ était utilisé à tort et à travers confirmeront.



C’est un langage qui peut faire des merveilles dans des mains expérimentées.



Mais entre les mains d’un stagiaire, c’est une arme nucléaire. " />





Donc je pense que Rust a tout a fait ça place dans les entreprise qui sont intéressées par des performances bas niveau mais ne sont pas capable de recruter 100% d’experts confirmés en C++





Le bas niveau demande forcément un excellent niveau d’expertise pour de nombreuses raisons. Mon opinion est que le bound checking ne suffit pas à changer cela…

 



Bien évidement que le bound checking ne fait pas tout. Il n’empêche que se débarrasser avec un surcoût généralement négligeable de toute une catégorie de bug très pernicieuse et dangereuse, c’est quand même un atout non négligeable.





C’est indéniablement un atout dans certains cas. Mais le bound checking n’a pas non plus que des avantages.



Dans un programme ou la performance prime mais qui a peu d’implications en terme de sécurité, l’absence de bound checking est un bon choix.



Avec la puissance des utilitaires modernes, je trouve qu’il est plus aisé d’atteindre un bon niveau de stabilité malgré l’absence de bound checking que de débusquer tous les points ou le bound checking ferait perdre en performances.





D’autant plus que si la sécurité mémoire et un argument intéressant de Rust, il propose bien plus que cela avec certaine capacités issues de langages fonctionnels.





On observe aussi ce mouvement dans les évolutions de C++.





Le problème c’est que ces technologies ne sont que de la mitigation de risque. Elles  visent à limiter les risques en cas de mauvaise utilisation, mais certainement pas a dédouaner le développeur du bound checking. Bien qu’ils utilisent ça, la plupart des navigateurs modernes sont encore victimes d’exploit mémoire.

 Alors si les développeurs se mettent a penser que ça peut remplacer le bound checking comme tu le suggères, je crains le pire …





Le bound checking est une solution connue et utilisée depuis très longtemps. Bien avant Java, C# ou Rust, il y avait le langage Pascal.



Comme dans beaucoup de cas de figure, la cohabitation de visions différentes traduit simplement le fait qu’il n’existe aucune solution miracle “panacée” qui apporterait uniquement des avantages sans aucun inconvénient et qui soit valable dans tous les cas de figure.



La bonne solution est toujours celle dont le rapport avantages/inconvénients est le meilleur en fonction de l’application souhaitée.



Autant on peut comprendre qu’on veuille utiliser du bound checking dans un navigateur web, autant un jeu vidéo solo n’a pas de raisons de l’utiliser car il ne pose pas spécialement de problème de sécurité.



Entre les deux, il y a quantité de cas. Par exemple, une base de données à haute performance n’a pas de raison de ralentir ses mécanismes internes avec du bound checking. Dans tous les cas, les requêtes qui lui sont adressées doivent être correctement filtrées. Avant l’exploit mémoire, c’est bien l’injection SQL qui est le risque principal. Et dans les services qui comptent des millions de serveurs, 5% de performances en moins peut représenter un surcout qui se chiffre en millions.



Bref, les problématiques de sécurité sont loin d’être l’unique préoccupation des programmeurs.





Attention, je ne dis pas que ces technologies sont mauvaises, bien au contraire. Mais il ne faut les voir que comme ce qu’elles sont, une réduction du risque d’exploitation, pas une solution au problème.

D’ailleurs Rust peut les utiliser pour l’imiter les risques liés aux blocs “unsafe”, ou à du code externe en C.





Mais paradoxalement, c’est vrai aussi pour le bound checking.



Car le bound checking ne supprime pas pour autant toute forme d’erreur mémoire. Par exemple, un bug sur le calcul d’un d’index peut aboutir à renvoyer les informations personnelles d’une autre personne sans pour autant être détectée par le bound checking. Elle ne peut être détectée qu’en cas de dépassement des bornes du tableau.



Ensuite, cette mesure ne s’attaque qu’aux failles provenant d’erreurs mémoires. Mais il y existe bien d’autres types de failles.



Bref, ce n’est pas parce qu’on utilisera du bound checking qu’on obtiendra pour autant des programmes sans failles.





Je ne parlais que du C qui, s’il a certes un peu évolué, a au fond assez peu changé. C’est vrai que le contrôle des types des paramètres de fonction ont apportés beaucoup, mais sans changer vraiment le langage.





Je suis d’accord. Mais au fond, l’évolution du C s’est fait par la création d’autres langages, dont le C++.

 



Le C++ par contre a en effet énormément évolué. Même un peu trop au point au l’empilement de nouveauté qui veulent changer la façon même d’aborder le langage, mais ne peuvent pas vraiment totalement renier les anciennes façon de faire, fait que le langage est inutilement complexe.





Le C/C++ ne sera certainement pas le langage de bas niveau ultime.



Cependant, malgré le fait que les langages qui ont fait mieux sur beaucoup de point sont légion, je trouve qu’aucun n’a réussi à conserver son équilibre extraordinaire entre rigueur, souplesse, performance et possibilités.

 



Un des avantages de Rust et de ne pas encore trop souffrir de son historique. Mais il est vrai que cet argument ne sera certainement plus valable s’il arrive a atteindre l’age du C++.





En même temps c’est aussi ce qui a fait de C/C++ un langage bien “poli par le temps”.



L’évolution s’est faite progressivement avec la volonté d’apporter des choses au programmeur tout en évitant d’apporter des inconvénients ou de réduire la souplesse.

Je trouve ce langage intéressant à plus d’un titre, mais je pense qu’il y a une grave erreur de communication dans l’affaire.



Je pense que certains arguments ne vont d’ailleurs pas manquer d’irriter les aficionados de C/C++.





le langage s’oriente très clairement vers ceux qui manipulent habituellement le C ou le C++, dont il veut garder les performances tout en apportant aux développeurs des éléments de langage de plus haut niveau.







Rust étant notamment memory safe,





Sauf que ces deux caractéristiques sont complètement contradictoires.



Ceux qui utilisent C/C++ de nos jours, c’est JUSTEMENT parce qu’ils veulent un langage SANS bound checking pour avoir de meilleures performances et un maximum de contrôle.



Il faut réaliser que le bound checking est bien l’une des caractéristique clivante qui sépare les camps des langages entre des langages comme C# ou Java d’un côté et C/C++ de l’autre.



Visiblement, Rust ne se positionne pas dans le même camp que C/C++…





De nombreuses failles ont été exploitées de cette manière, en exploitant simplement des dépassements de mémoire tampon et autres types de faille.





Sauf qu’aujourd’hui, il faut relativiser…



D’abord, avec toutes les techno de protection du code natif qui ont été implémentées ces dernières années comme le DEP ou l’ASLR ou encore les protections de pile, l’exploitation de ce genre de faille n’est pas du tout facile.



Ensuite, les problèmes de dépassement de mémoire tampon étaient principalement le fait de vieux code écrit en “vieux c” quand on manipulait des buffers et des chaines avec des pointeurs presque à chaque ligne de code. Dans ce genre de programmation, on pouvait commettre une erreur lourde de conséquence presque à chaque ligne.



Enfin, c’est devenu beaucoup plus sécurisé en C++ moderne correctement écrit car les manipulations de la mémoire passent logiquement par des classes à des endroits restreints et centralisés qu’il est beaucoup plus facile de contrôler. Il est même relativement trivial d’implémenter du bound checking quand on le désire.



Au passage, implémenter un modèle de tableau avec bound checking en C/C++ est un exercice de niveau débutant.





le parseur MP4 était un bon candidat pour un premier composant en Rust.





Les utilisateurs de C/C++ utilisent ce langage car ils sont plutôt partisan d’un code bien relu, audité et stabilisé. Pour eux, le bound checking, c’est la voie de la facilité parce qu’il aura toujours un coût en matière de performance.



D’ailleurs, comme on peut le constater tous les jours avec des langages comme PHP le bound checking n’est pas non plus une recette miracle contre les failles qui permettrait pour autant de s’abstenir de sécuriser et relire son code.





(Les fonctionnalités multithread de rust)





La encore, en proposant un modèle robuste et prêt à l’emploi, Rust s’inscrit dans une logique très différente de C/C++ et va plutôt dans le sens de C# ou Java.



La philosophie en C/C++ est complètement à l’opposée : donner le maximum de souplesse au langage pour permettre d’implémenter le modèle de son choix plutôt que de proposer un modèle précis prêt à l’emploi.



IMHO, je pense que Rust pourrait être un bon concurrent de C# ou Java plutôt que de C/C++.