Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Sûrement une question de sécurité nationale parmi de nombreuses autres, tout comme une nation européenne pourrait s’intéresser à l’utilisation d’une distribution libre pour son parc de machine plutôt que d’autres solutions contrôlée par une entreprise étrangère, introduisant potentiellement certaines failles pour sa sécurité nationale par exemple.Envoyé par Issam
heuu 1 sec ,
c'est quoi le rapport entre la maison blanche et les languages de programmation ?
Les cyber attaques sont de plus en plus commanditées par des états. Elles concernent tout le software déployé dans un pays dont les machines sont retournées pour en faire des zombies qui attaquent d'autres machines ou sont détournées pour servir de vpn' like à l'attaquant. Même dans le cas d'une infection par ransomware, l'activité d'une entité économique est détruite, entrainant sa faillite, chômage ou simplement des coûts énormes en assurance.heuu 1 sec ,
c'est quoi le rapport entre la maison blanche et les languages de programmation ?
Coordonnée par les états, l'accumulation de telles attaques peut détruire l'économie d'un pays.
Autre scénario : l'attaque militaire : on infecte le software de pilotage de machines peu critiques donc mal protégées pour forcer la consommation électrique tandis que des applications de gestion d'énergie domestiques (thermostats intelligents) sont hackées ou désactivées par saturation pour empêcher la régulation de la consommation. Dans le même temps, on attaque le réseau électrique et les centrales pour provoquer un blackout.
Une fois que tout est en panne, une vraie attaque militaire est possible.
Même sans attaque physique, le pays est durablement affaibli par un blackout.
C++ est un compilateur C auquel on applique une surcouche. (Théoriquement, des directives de préprocessing suffisent)
Les vulnérabilités viennent de la cohabitation de pointeurs sur data et pointeurs sur code. Les premiers permettent de trouver les seconds et même de les modifier (buffer overflow)
Je connais trop mal Rust pour savoir comment il sécurise la ram mais une simple garbage collection rend les pointeurs indépendants de la compilation. Les adresses changent à chaque appel de GC, le pointeur de pile n'est pas le registre SP du CPU... etc...
C'est, en très résumé, le problème de tous les compilos de cette génération.
Personnellement, je lis le C comme ma langue maternelle et sa disparition me met un méchant coup de vieux. J'espère que LLVM et WebAssembly permettront de continuer à écrire en C mais pour les performances imbattables, il faudra sans doute migrer vers Rust (ou go ?)
Bref, c'est dommage !
A l'origine du CC++, les experts étaient rares et les machines coûtaient des mois de salaire. Aujourd'hui, on se forme en ligne et on trouve des machines utilisables pour quelques centaines d'euros. La démocratisation du matériel et la gratuité du logiciel poussent pas mal de standards vers l'obsolescence (e-mail ? SMTP, pop, FTP, ...)
Je me fais vieux
Heu, mais non...
Que l'on n'utilise plus le C++, je peut le comprendre. Mais pas à cause de "fuites mémoire", mais plutôt parce qu'il est devenu un monstre tentaculaire, et cela totalement inutilement. J'ai arrêté le C++ (alors qu'à ses débuts, il apportait vraiment un + par rapport au C) il y a bien longtemps. J'ai eu ce déclic d'éviter le C++ quant j'ai voulus apprendre en profondeur le système de "Template", et que pour se faire, j'avais acheté le livre d'Andrescu (ou un nom assez proche, je ne me rappel plus bien), et qui nécessitait plus de 700 pages, pour expliquer comment maîtriser le sujet). 700 pages, pour une fonctionnalité, c'est délirant, tout simplement. Et ça ne s'est pas arrangé avec le temps. On a ajouté au C++ des fonctionnalité "de pointe" parce que c'était POSSIBLE, mais pas parce c'était NECESSAIRE. Le C++ est maintenant un gloubiboulga imbuvable.
Quant au C, c'est un langage très simple, facilement compréhensible. Je suis d'accord qu'il PERMET de faire des bêtises, mais ce n'est pas à cause du C en lui-même, mais de développeurs incompétents et/ou dont on ne laisse pas le temps d'écrire du code propre et lisible. Si un charpentier se tape sur les doigts avec un marteau, ce n'est pas le marteau qu'on accuse.
De plus, le C est tellement répandu, qu'il ne disparaîtra pas avant des lustres. Le COBOL est toujours utilisé dans les systèmes bancaires, et les tentatives pour le remplacer par du C++, Java ou C# ont toutes été avortées. Il en ira de même avec le C. Je ne connais pas Rust plus que ça, mais j'ai regardé son système de gestion de la mémoire, et il n'est pas si exceptionnel que ça.
Il y a d'ailleurs un langage qui traite déjà ce "problème", et c'est le langage Ada. Le chiffre de +/- 15% des bugs dans linux dû aux "dépassement de buffer", soit. Mais que fait t'on des 85% des autres causes de bug ? On les oublies ? Il vont disparaître d'eux-mêmes en réécrivant tout ? Avec de la rigueur, en ne se laissant pas emporté par les "ajouts" plus que douteux, en en restant à du code SIMPLE, LISIBLE et MAINTENABLE, le C est un langage plus que suffisant, même si lui aussi, il a évolué pas forcément dans le bon sens.
On est à une époque où, plus généralement, on complexifie inutilement trop de choses pas par nécessité, mais parce que c'est possible.
Je suis totalement opposé à cette manie. L'informatique, à ses débuts, aurait dû simplifier tant de choses, mais puisque c'est possible, on en fait trop, et on gaspille plus de papier qu'avant. Enfant, lorsque j'allait chercher un livre à la bibliothèques, on notait mon nom sur une fiche en papier, et ça fonctionnait très bien. Maintenant, il faut créer un compte, attendre 10x plus de temps que la dame "encode" un flot d'informations totalement inutiles, sur un PC qui rame comme pas possible, et on perd un "pognon de dingue" pour la maintenance d'une chose inutile. Ce n'est qu'un exemple. Il y en a tant d'autres. Avec un raisonnement semblable, on va un jour essayer de remplacer la roue, parce que des voitures "autonomes" sont perdues dès qu'elles quittent une autoroute bien propre avec des belles lignes blanches. Ah mais si c'est Musk qui te dis que "l'autopilote full self driving de la mort qui tue", sera disponible dans 6 moins (ce qu'il répète depuis presque 10 ans), qu'on établira une colonie sur mars en 2020 (oups, on est en 2024 et 1 essais sur 2 pour poser une sonde sur la lune se plante lamentablement).
On est allez sur la lune il y a plus de 50 ans avec une calculatrice comme ordinateur de bord, mais on a toutes les peinent du monde a tenter d'y retourner. C'est la faute du C aussi ? Non, je ne pense pas.
Bah, c'est pas grave, l'IA va tout régler, non ? Il n'y a qu'a demander à ChatGPT "fait moi un bidule pour aller sur la lune", et les milliards de robots ferons cela en 30 secondes ;-)
Ah, ça fait du bien de se défouler un peu :-)
C'était vrai aux débuts de C++, mais de nos jours il s'est trop complexifié et a divergé sur certains points. Même s'il embarque encore une bonne partie de l'héritage du C, ce n'est plus une simple surcouche depuis au moins 20 ans.
C'est malheureusement plus compliqué que ça. Il existe des technologies, tout à fait utilisables en C, qui permettent déjà de se protéger de ce que vous décrivez, comme la DEP (protection contre l’exécution des données) ou l'ASLR (positionnement aléatoire des adresses). C'est très bien, mais ça n’est que de la mitigation : les bugs sont toujours là et des attaquants assez malins arrivent encore à trouver des moyens pour les exploiter.
Rust n'utilise pas de Garbage Collector pour la gestion mémoire. Sur ce point il fonctionne exactement comme C ou C++, excepté qu'il impose au programmeur des règles à respecter sur la façon d'utiliser les références (l’équivalent des pointeurs), ce qui permet, dès la compilation de garantir que l'on ne peut jamais manipuler une données non valide.
Je vois pas trop le rapport avec WebAssembly ou LLVM. Le C n'est de toute façon pas près de disparaitre ou de perdre en performance. Si on a pas pu se débarrasser de COBOL alors que ça fait plus de 30 ans qu'on essaie, je pense que le C en a pour au moins encore autant, probablement plus
Sauf que les deux tiers des vulnérabilités critiques qu'on trouve dans tous les gros logiciels C++ viennent d'erreurs mémoire. Donc soit les incompétents sont partout, soit les meilleurs experts font aussi parfois des erreurs (probablement un mix des deux). Dans tous les cas, on a un gros problème à résoudre, connu depuis plus de 40 ans, et tous les moyens qui on un effet mesurable sont bon à prendre. S'il suffisait de désigner des coupables, on aurait tourné la page depuis longtemps.
Tout dépend de la définition que l'on a d'exceptionnel.
En un sens il est vrai que, techniquement, la manière de gérer la mémoire n'est pas exceptionnelle. Structurellement, on a une pile classique et un tas alloué dynamiquement, tout comme en C. On gère les ressources en RIIA comme en C++. Même les principes centraux en Rust que sont l'ownership et les lifetime n'ont pas été inventées par Rust. Ce sont des bonnes pratiques que l'on recommandais déjà en C et C++.
Mais le fait que le compilateur garantisse la stricte application de ces principes est exceptionnel, car pour le moment sans d’équivalent dans aucun autre langage (actuellement utilisable) de ma connaissance. Le fait de pouvoir à la fois empêcher totalement les vulnérabilités mémoires tout en conservant l'efficacité du système de gestion mémoire de C fait tout l’intérêt du Rust.
En effet Ada permet de traiter des problématiques de sécurité y compris certaines que Rust ne sait pas (encore) traiter, mais inversement il y a des problématique de sécurité que Rust traite mieux que Ada, qui est d'ailleurs en train d'ajouter un système de borrow checker, inspiré directement de Rust.
Les deux langages ont leur intérêt propre, Rust étant quand même plus orienté productivité et il reste plus proche du C que Ada, ne serait-ce qu'au niveau de la syntaxe.
Les dépassement de buffer ne sont qu'un seul type d'erreur de sureté mémoire. Rust prévient aussi les autre erreurs de sureté mémoire comme l'utilisation de mémoire déjà libérée, les doubles libérations, les accès à la mémoire non initialisée ou les accès concurrents à la même donnée mémoire.
Je connais pas le compte exact pour le cas particulier de Linux, mais dans quasiment tout les gros projets C et C++ qui ont fait le calcul, on arrive à environ 2/3 des vulnérabilités importantes liées à des erreur de sureté mémoire. Ça en laisse un bon tiers, mais ça reste un progrès très important.
Il n'y a pas forcément besoin de tout réécrire du jour au lendemain. C'est sur que réécrire de zéro une base de code complexe mais bien maitrisée n'est pas forcément une bonne idée. Rust n'a pas vocation à écraser systématiquement l’existant si on n'en ressent pas le besoin. Par contre pour les nouveaux projets et les cas on on a de toute façon besoin de faire une réécriture, il serait idiot de ne pas considérer ces avantages face aux langages qui n'offrent pas la même sécurité.
Je pense qu'il y a confusion entre le C et le C++, parce que le C est probablement le langage qui a le moins évolué ces 20 dernières années, et le peu qui a changé c'est surtout pour le rendre plus propre, pas plus complexe.
Alors autant je suis en partie d'accord sur le fait qu'on a beaucoup trop complexifié certaine choses, il faut pas non plus tomber dans le "c'était mieux avant". Il reste beaucoup de choses qui changent de manière tout à fait justifiées.
C'est plus le cas depuis 20 ans déjà.
Rien à voir mais c'est bien essayé.
Bon déjà Rust n'a pas de GC. Et je vois pas le lien entre un GC et un compilo, mais bon, le reste n'a guère de sens non plus donc on est pas à ça près.
Lire un langage comme sa langue maternelle n'empêche pas ce langage d'être criblé de défaut (et c'est le cas de tous les langages, même Rust). Le problème dans le cas du C c'est que la gestion de la mémoire est manuelle et surtout qu'il y a énormément de undefined behaviours (bonjouuuuur).
Code : Sélectionner tout - Visualiser dans une fenêtre à part i++ + ++i
Ah clairement, le C++ est horriblement complexe. Par-contre oui, la gestion de la mémoire (de manière générale) est aussi un sujet horriblement complexe que C++ ne gère pas du tout (un poil mieux que le C grâce aux destructeurs et les smart pointers mais ça reste insuffisant).Que l'on n'utilise plus le C++, je peut le comprendre. Mais pas à cause de "fuites mémoire", mais plutôt parce qu'il est devenu un monstre tentaculaire, et cela totalement inutilement. J'ai arrêté le C++ (alors qu'à ses débuts, il apportait vraiment un + par rapport au C) il y a bien longtemps. J'ai eu ce déclic d'éviter le C++ quant j'ai voulus apprendre en profondeur le système de "Template", et que pour se faire, j'avais acheté le livre d'Andrescu (ou un nom assez proche, je ne me rappel plus bien), et qui nécessitait plus de 700 pages, pour expliquer comment maîtriser le sujet). 700 pages, pour une fonctionnalité, c'est délirant, tout simplement. Et ça ne s'est pas arrangé avec le temps. On a ajouté au C++ des fonctionnalité "de pointe" parce que c'était POSSIBLE, mais pas parce c'était NECESSAIRE. Le C++ est maintenant un gloubiboulga imbuvable.
Oula, dire que le C est simple, c'est une grave erreur. C'est un langage très difficile. Et c'est pas qu'il PERMET de faire des bêtises mais qu'il requiert du développeur une quantité phénoménale d'efforts supplémentaires pour s'assurer que tout fonctionne correctement. Et c'est sans parler de tous les undefined behaviours. Ce n'est pas une histoire de compétence (sinon je suppose que tu te considères meilleur que les ingés chez google/linux et consorts qui sont tous en train de lentement mais sûrement passer à Rust justement parce que la gestion de la mémoire notamment est trop complexe) mais bien d'un langage qui ne fournit pas ce qu'il faut pour permettre d'écrire du code qualitatif.Quant au C, c'est un langage très simple, facilement compréhensible. Je suis d'accord qu'il PERMET de faire des bêtises, mais ce n'est pas à cause du C en lui-même, mais de développeurs incompétents et/ou dont on ne laisse pas le temps d'écrire du code propre et lisible. Si un charpentier se tape sur les doigts avec un marteau, ce n'est pas le marteau qu'on accuse.
Donc parce que ça ne résoud pas 100% des problèmes on doit laisser tomber ? Logique... Et le code du kernel linux ou même de projets aussi gros/vieux ont des millions de lignes de code. Clairement, même du code SIMPLE (comment ça peut être simple quand c'est aussi gros ? Mystère), LISIBLE (ba je suppose qu'avec des commentaires ça aide) et MAINTENABLE (ah ba là va falloir définir ce que t'entends par là), le C n'est pas suffisant (sinon pourquoi y aurait-il d'autres langages ?). Par-contre les seuls ajouts du C depuis C89 ce sont des types avec des tailles définies (j'apprécie d'être sûr que mon char soit signé et de un octet, ce qui n'est pas défini dans la norme C) et des undefined behaviours qui sont lentement mais sûrement définis.Il y a d'ailleurs un langage qui traite déjà ce "problème", et c'est le langage Ada. Le chiffre de +/- 15% des bugs dans linux dû aux "dépassement de buffer", soit. Mais que fait t'on des 85% des autres causes de bug ? On les oublies ? Il vont disparaître d'eux-mêmes en réécrivant tout ? Avec de la rigueur, en ne se laissant pas emporté par les "ajouts" plus que douteux, en en restant à du code SIMPLE, LISIBLE et MAINTENABLE, le C est un langage plus que suffisant, même si lui aussi, il a évolué pas forcément dans le bon sens.
Ouf, ba faut avertir le monde et lui dire de s'arrêter parce que t'es pas d'accord alors.On est à une époque où, plus généralement, on complexifie inutilement trop de choses pas par nécessité, mais parce que c'est possible.
Je suis totalement opposé à cette manie.
Il y a des points sur lesquels je suis d'accord, mais les raisons ne sont pas juste "parce que les gens veulent tout complexifier pour le fun". C'est un mélange de marketing douteux, d'effet de mode bien pourri (l'écosystème front-end du web est une catastrophe) mais aussi des fois des besoins légitimes pour tenter de faire des projets bien cool pour faire avancer nos connaissances. Bref, les nuances, etc....
Désolé mais s'il est vrai que le compilateur voit son parser fortement enrichi par c++, le modèle des __CDecl est toujours là. Les headers de librairies sont toujours là et les appels de méthodes suivent encore le même protocole qui empile l'adresse de retour après les arguments. (références sur code après une valeur traçable donc)
Le principe du compilateur qui adresse les registres est le même qu'en C. Les registres sont formattés comme en C etc...
Les fondamentaux du C sont là et le seul moyen de les sécuriser consiste à adresser un runtime. En attendant, on peut sécuriser le CC++ en déclarant les strings C dans le heap ou en faisant des mallocs. Les CStrings sont plus agiles et le new du C++ est plus fiable.
Pourriez vous éviter de dire "rien à voir mais bien essayé (smiley)" svp ? Ca ne dit rien de précis et si c'est une blague, elle laisse de marbre.
i++ + ++i
le résultat est 2 i + 1 ; // i est incrémenté deux fois
Il n'y a aucune ambiguité dans cette expression, par contre elle est difficile à lire et ne donne pas une bonne opinion du développeur qui ferait mieux d'écrire
maj = 2 * i + 1;
i += 2;
Je ne pense pas que l'heure soit au démonstrations de connaissance. J'ai fait auditer du code C sur la sécurité par des services gouvernementaux. J'aurais aimé discuter plus longtemps avec eux mais en gros, il ressort que les pointeurs sur code sont trop exposés et que l'adressage des registres CPU est trop explicite (en particulier AX et le pointeur de pile). La gestion des strings et l'opérateur "[]" des tableaux sont impossibles à sécuriser à 100%. Au final, j'ai obtenu la certification mais le code résultant n'avait plus grand chose à voir avec l'esprit du C ni même avec un quelconque langage moderne. Néanmoins le compilateur acceptait ce code et il répondait aux impératifs de sécurité critiques.
Ce débat caché autre chose.
Bonjour,
Le problème n'est pas les language de programmation.
Les développeurs professionnels n'ont aucun problème de gestion de la mémoire avec C ni C++. Que ceux qui ne font pas de contribution sur des logiciels de classe mondiale nous explique ça ou ça c'est super ça les occupe. J'adore moi ceux qui m'explique la vie...
Quand tu participes à Windows, Office, SQL Server ou Exchange ou bien en mode Open-source à des GitHub reponcomme CoreClr, BaseFx (c'est .NET ces deux trucs), Service Fabric (le provisioning layer de Azure depuis 15 ans, socle de tout...), WinUI, STL de Visual C++, WinTerminal bref tout ce que Microsoft peut mettre en public sur GitHub ou bien... Le monde d'en face comme Linux, GIMP, Libre Office, KDE, Chromium, VLC, KDE, les libs de Linux écrites en C et des fois en C++, mais aussi tout ce qui le joyau des compilateurs que sont GCC, Clang et LLVM -> tout ceci sont les fondations de nos softwares critiques utilisés partout.
Tout est fait en C et C++.
Même les Mac sont des BSD forked.
" C++ is the invisible foundation of everything "
By Bjarne Stroustrup.
L'industrie utilise C et maintenant C++ depuis 40 ans.
Moi s je veux bien que les gens nous explique C et C++ sont unsafe.
C'est du bullshit.
Google pour éviter de vous expliquer pourquoi Microsoft veut écrouler Windows et Office (oui Monsieur) pour faire uniquement du Cloud... Mark Russinovitch est un asshole de putain de connard qui se voit déjà ceo un jour.
Rust a déjà essayé de s'insérer dans Windows.
On en veut pas nous les vrais contributeurs de Windows.
Messieurs, chez Microsoft on fait tout en C et C++ depuis 4 décennies. Ces naturel comme l'air et l'électricité.
Moi je fais des Books (6 dont 2 chez Dunod) et je j'ai donné les cours en école d'ingénieurs sur c et c++ pour le génie logiciel et les jeux vidéos.
J'ai vu comment certains essayent de nous dessouder depuis 20 ans.
Java.... .NET... Le go avec kubernetes et Google.
Un seul argument ou deux... et non Microsoft.
En Rust, on compile x20 moins rapide que C/C++.
Il est impossible de faire des Structures ou des constructions qui pointe sur des trucs et qui se repointent dessus.
Le secret d'une UI style Ribbon contextuel c'est que j'ai des hashtables qui contiennent des pointers (std::shared_ptr) qui pointent sur des items shared pour accéder à des choux et des carottes partout.
Le secret des softwares de classes mondiale c'est on fait tout en OOP et des millions de fichiers et classes et après le magique cest la performance et ça se fait en ayant accès en direct à la mémoire et a des pointeurs vers des objets qui eux sont bien rangé et bien classifié et bien compartimentés.
La move semantic ne permet pas cela.
Les lambdas non plus.
L'async est à ne pas mettre partout.
Les structures simples juste de Data -> uniquement pour le code fonctionnel
Ces gens ne savent pas que les softwares que TOUT le monde utilise sont fait en C/C++ et que en interne la beauté de la performance c'est que NOUS savons utiliser la mémoire de manière subtile, efficace et la performance est un métier.
Continuer d'être au niveau 1/1000 de la notion de secure unsafe et mémoire c et c++ danger.
Ceci est stérile.
L'existant est là. 4 décennies.
Quid des interopérabilité ?
Les thunking layers ?
Même Mozilla Firefox n'est faitvquev50% en Rust.
Mdr.
Ce débat est bullshit.
On ne réécrit jamais tout en Rust.
Impossible.
Il faut coexister.
Rust est un langage qui nécessite plus que de la bonne volonté pour être maîtriser. Move semantic, async, borrow checker, principe et philosophie -> faites vous vous-même votre propre expérience.
Derrière ce débat -> y a de la désinformation pour justifier le future que certains aimeraient.
Dernier truc : les fondamentaux de tous les GAFAM sont des millions et millions de lignes de C/C++.
Rust existe depuis 7..10 ans.
L'invasion n'est pas encore réussie.
Mdr et lol 😂😆.
Allez je vous laisse.
Vos mobiles, laptop, serveurs et cloud -> c'est tout du C et C++ à 99% donc ces gens du marketing amusent le soleil.
Vive Mickey, linux et mort aux cons.
Vive le Général 🇫🇷.
Christophe PICHAUD 🇫🇷
Clown Professionel & Supo de Satan
Pote à Bjarne Stroustrup et Herb Sutter.
Lockheed Martin PREPAR3D F-35 Ecosystem
la maison blanche a fait appel à des experts simultanément en C++ et en rust pour décider en toute connaissance de cause je présume
BenAbdo
Mais d’après mes connaissances, le langage Go est supérieur à Rust sur de nombreux aspects, notamment en termes de simplicité et de rapidité, alors pourquoi n’est-il pas recommandé ?
Il existe des bases de données qui répertorient les bugs, vulnérabilités, erreurs communes, etc. depuis des années, afin d'améliorer la sécurité des logiciels. C'est plusieurs centaines de milliers de bugs qui sont répertoriés et il y en a des milliers qui sont ajoutés chaque année. Les erreurs les plus communes sont encore les use-after-free, les buffer overflow, les out-of-bouund write, etc. Donc des trucs de mémoire bas niveau.
Et Microsoft, Linux, etc. etc. sont pas du tout épargnés par ces bugs (une centaine de vulnérabilités déclarées par Microsoft rien que cette année et on n'est qu'en février).
C'est améliorable. Mais il ne faut pas non plus faire l'autruche et prétendre qu'il n'y a pas de problème.
Ce n'est pas le C qui est performant, c'est le compilateur qui l'est nuance.
Rien n’empêcherai que Rust soit plus performant que du C, si son compilateur est mieux foutu.
J'ai rien compris, je ne vois pas le rapport avec le C, sauf s'il code en asm.il ressort que les pointeurs sur code sont trop exposés et que l'adressage des registres CPU est trop explicite (en particulier AX et le pointeur de pile).
(Après si on parle de sécurité , je crois que faut d'abord oublier le x86).
C'est pourtant un cas d'école bien connu de Undefined Behaviour : modifier la valeur d'une variable plus d'une fois dans une séquence. Le compilateur est libre de faire ce qu'il veut avec ce genre d'expression.
En matière de SGBD il faudra donc se débarrasser des logiciels libre comme MariaDB, MySQL, SQLite et PostGreSQL. En effet, ils sont incapables de protéger la mémoire qu'ils utilisent et ceci pour deux raisons :
1) la gestion des threads et du cache est confiée à l'OS, alors que dans les SGBDR d'entreprise comme IBM DB2, Oracle Database ou MS SQL Server elle est traitée de manière interne et relativement protégée...
2) certains SGBDR d'Entreprise y ajoute des enclaves sécurisées pour les données sensibles, chiffrées... C'est le cas par exemple de Microsoft SQL Server
https://learn.microsoft.com/fr-fr/sq...l-server-ver16
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
petites précisions...
Bon, si un développeur écrit des choses du style i++ + ++i, je pense que oui, clairement, c'est le développeur qui est en cause. Un programme est plus souvent (re)lu qu'écrit.C'est plus le cas depuis 20 ans déjà.
Rien à voir mais c'est bien essayé.
Bon déjà Rust n'a pas de GC. Et je vois pas le lien entre un GC et un compilo, mais bon, le reste n'a guère de sens non plus donc on est pas à ça près.
Lire un langage comme sa langue maternelle n'empêche pas ce langage d'être criblé de défaut (et c'est le cas de tous les langages, même Rust). Le problème dans le cas du C c'est que la gestion de la mémoire est manuelle et surtout qu'il y a énormément de undefined behaviours (bonjouuuuur).
Code : Sélectionner tout - Visualiser dans une fenêtre à part i++ + ++i
Ah clairement, le C++ est horriblement complexe. Par-contre oui, la gestion de la mémoire (de manière générale) est aussi un sujet horriblement complexe que C++ ne gère pas du tout (un poil mieux que le C grâce aux destructeurs et les smart pointers mais ça reste insuffisant).
Oula, dire que le C est simple, c'est une grave erreur. C'est un langage très difficile. Et c'est pas qu'il PERMET de faire des bêtises mais qu'il requiert du développeur une quantité phénoménale d'efforts supplémentaires pour s'assurer que tout fonctionne correctement. Et c'est sans parler de tous les undefined behaviours. Ce n'est pas une histoire de compétence (sinon je suppose que tu te considères meilleur que les ingés chez google/linux et consorts qui sont tous en train de lentement mais sûrement passer à Rust justement parce que la gestion de la mémoire notamment est trop complexe) mais bien d'un langage qui ne fournit pas ce qu'il faut pour permettre d'écrire du code qualitatif.
Donc parce que ça ne résoud pas 100% des problèmes on doit laisser tomber ? Logique... Et le code du kernel linux ou même de projets aussi gros/vieux ont des millions de lignes de code. Clairement, même du code SIMPLE (comment ça peut être simple quand c'est aussi gros ? Mystère), LISIBLE (ba je suppose qu'avec des commentaires ça aide) et MAINTENABLE (ah ba là va falloir définir ce que t'entends par là), le C n'est pas suffisant (sinon pourquoi y aurait-il d'autres langages ?). Par-contre les seuls ajouts du C depuis C89 ce sont des types avec des tailles définies (j'apprécie d'être sûr que mon char soit signé et de un octet, ce qui n'est pas défini dans la norme C) et des undefined behaviours qui sont lentement mais sûrement définis.
Ouf, ba faut avertir le monde et lui dire de s'arrêter parce que t'es pas d'accord alors.
Il y a des points sur lesquels je suis d'accord, mais les raisons ne sont pas juste "parce que les gens veulent tout complexifier pour le fun". C'est un mélange de marketing douteux, d'effet de mode bien pourri (l'écosystème front-end du web est une catastrophe) mais aussi des fois des besoins légitimes pour tenter de faire des projets bien cool pour faire avancer nos connaissances. Bref, les nuances, etc.
Merci pour l'ironie, et non, il ne faut pas avertir le monde. Le monde s'en fout complètement...
Je ne pense pas avoir dit que qu'il ne fallait rien faire parce que les "fuites mémoires" ne sont qu'une partie du problème. Oui, il faut faire quelque chose: Mieux former les développeurs. Comme ceux qui écrivent des trucs du genre i++ + ++i, par exemples.
Je ne pense pas avoir dit que je me prenait pour un génie. Bien au contraire, c'est pour cela que je me restreint a n'utilisé que des choses bien maitrisées, que j'ai le code le plus simple possible, le plus clairement possible. C'est plutôt de l'humilité, ce qui semble manquer à pas mal de gens depuis quelques temps, tout comme le bon sens.
Je ne prétend nulle part que je suis meilleurs que les 100.000 employés de Google, mais je ne suis pas certains qu'ils soient les meilleurs au monde... Si c'est eux qui ont pondu Gemini, que Google a "perdu" des milliards en bourse parce que leur bidule d'IA sort connerie sur connerie (comme les autres IA), il doit bien y avoir un soucis quelques part chez eux, non ? Un roi de France noire et un pape asiatique, faut le vouloir pour sortir ce genre de bêtises. Mais c'est normal, leur IA, ils ne lui donne pas à manger des sources vérifiables et vérifiées, non, ils pompent tout ce qui se trouve sur Internet et si l'IA doit se servir de ça pour sortir des choses intelligentes, elle est mal barrée la pauvre. Et oser dire que "c'est une boite noire" qui peut avoir des "hallucinations", mais qu'on prétend que c'est mieux, soit. Je passe mon tour. Il y'a des cas bien précis d'IA qui fonctionnent bien (comme l'analyse de radiographie en médecine pour détecter des mélanomes par exemple). Mais elles ont été "éduquées" avec des sources fiables et contrôlées et vérifiée.
Je ne vois pas dans les réponses ce qui contredit ce que j'ai écrit.
Sérieusement, je ne suis certainement qu'un pauvre vieux débile de programmeur, qui pense que "c'était mieux avant". Bein, oui, c'était mieux avant, quand les développeurs étaient mieux formés, que le moindre gars qui a survolé 20 bouquins du genre "apprendre le C++ en 15 jours" et qui prétend connaître et maîtriser 25 langages me semble bien présomptueux. Il y a un manque de bons développeurs, le dernier que j'ai croisé ne savait même pas quelle était la différence entre la mémoire allouée sur la pile et celle allouée dans le heap...
Le métier de développeur, c'est un métier difficile, je ne pense pas avoir dit le contraire. C'est justement parce que c'est difficile qu'il faut être bien formé, savoir ce que l'on fait et pourquoi on le fait. Mais le développeur n'est pas le seul coupable des soucis. Il y a un appauvrissement global de l'instruction en général depuis des années. Il suffit de voir les classements pisa. Quand on voit des archives de l'Ina et qu'on voit comment des jeunes étudiants qui sortaient du primaire il y'a 50 ans s'exprimaient en sachant utiliser plus que 50 mots de vocabulaires, par rapport à ce que l'on entend maintenant, c'est d'une tristesse a désespérer. Nos jeunes ne sont pas coupables, si on en est a former en une semaine des profs pour qu'il y ait juste quelqu'un devant eux, que la critique n'est plus permise, oui, c'était mieux avant.
Mais bon, je dois me faire vieux, n'être qu'un réactionnaire. Alors que je ne sais plus qui l'a dit dans les réponses avant, c'est un débat stérile. Alors je retourne dans ma grotte, il y fait frais, c'est mal éclairé, mais j'en connait les moindres recoins :-)
Sans rancune, bonne vie et prospérité.
Point positif de ce genre d'annonce, forcer le comité C++ a fournir un "safe" C++ le plus vite possible.
De toute façon il a va clairement de la "survie" à long terme de C++.
D'après Bjarne Stroustrup c'est possible et c'est même un des objectifs de C++ (je suppose qu'il a raison).
Je vous laisse regarder:
Et lire:
https://www.open-std.org/JTC1/SC22/W...23/p3038r0.pdf
Clairement le "SG23 Safety and Security" a du boulot.
Sur mes projets j'utilise l'outil d'analyse statique fournit avec Visual Studio 2022 et Sonarlint. Pour être honnête il sont très efficaces (use after free, ownership, lifetime, bounds...) si c'est écrit en C++ moderne (pas de C array, pas de cast C et tout un tas d'autres règles...). Les problèmes identifiés par https://alexgaynor.net/2019/apr/21/m...-wont-save-us/ ou https://neosmart.net/blog/modern-c-isnt-memory-safe/ sont détectés... Mais ce n'est pas une preuve absolue en soi.
It's time to kickass nvidia and chew 3dfx/ati bubblegum !
Bien sur que personne de censé n'écrira ça, c'est juste un exemple assez connu de "Undefined Behaviour" qui a l'avantage de tenir en quelques caractères. Ce n'est clairement pas le cas le plus discret, pourtant commandantFred ne l'a pas correctement identifié, et ce n'est probablement pas parce qu'il est idiot ou mal formé. En fait je ne connais pas grand monde, qui connaisse les presque 200 cas qui entrainent des UB dans la spécification du C, à part peut-être certains développeurs de compilateurs. Et même quand on connait un UB, ça ne veut pas dire que l'on pourra l'identifier dans tous les cas pratiques dans du code réel. Tous les humains sont faillibles.
Même dans des gros logiciels critiques, très surveillés et maintenus par des experts, on a la majorité des failles critiques qui viennent de la sureté mémoire. Si la formation était une solution suffisante, le problème n'existerait plus depuis longtemps dans les logiciels où l'on porte de l'attention à la sécurité.
C'est assez comparable au code de la route en fait : les conducteurs bien formés ne devraient théoriquement pas causer d'accident. Et pourtant, malgré l'épreuve du permis de conduire, on a toujours des accidents de la route, car la pratique de la conduite, tout comme la pratique du codage, repose sur avant tout sur l'humain.
C'est pour cela que c'est important d'améliorer la sécurité des langages, tout comme on améliore la sécurité des voitures.
Et c'est très bien, mais si c'est vraiment le cas, je ne vois pas pourquoi ne pas considérer sérieusement les apports de Rust pour la sécurité. L'humilité, c'est aussi prendre en compte que l'humain restera toujours faillible, et qu'il est intéressant qu'il puisse se reposer sur des outils qui prévienne ses erreurs.
Pour reprendre la comparaison avec l'automobile : on peut être un bon conducteur, très prudent, et quand même mettre sa ceinture de sécurité.
Ça correspond à pleins de langages, pas sûr que ce soit vraiment un argument pour dire que c'est juste une surcouche étant donné que 2 codes similaires en C/C++ risque fort de donner des ASM différents.
Et comme en Rust aussi. Du coup Rust est une surcouche de C parce qu'il utilise le même backend ?
Je pense qu'on peut simplifier en disant que tu ne comprends pas ce que "sécurité" veut dire.
"En attendant, on peut sécuriser le CC++ en déclarant les strings C dans le heap ou en faisant des mallocs." -> Donc on peut simplifier en disant que déclarer une string sur la heap ou dans la stack "sécurise" le code.
Pourriez vous éviter de dire "rien à voir mais bien essayé (smiley)" svp ? Ca ne dit rien de précis et si c'est une blague, elle laisse de marbre.
Comme l'a souligné Uther, c'est un cas classique de undefined behaviour. Ce qui est dommage quand on prétend avoir fait auditer son code pour de la sécurité...
Non en effet.
Encore une fois, ce n'est pas le sujet ici.
Il faut s'interroger sur le fait que Google, le créateur de Go, est l'un des premiers financeurs de la fondation Rust, l'utilise sur certains produits comme Android OS et le supporte dans le projet chromium.
Pour la rapidité, je n'ai pas les mêmes informations.
Ben en fait, c'est bien le développeur qui fait le "miracle" en C. Les gains en performance de C par rapport à C#.net, en faisant un portage de code strict, s'arrêtent aux boucles (2 ou 3 cycles d'horloge par itération) l'usage des pointeurs explicites (1 ou 2 cycles). L'arithmétique sur pointeurs, c'est juste quelques nano secondes parce qu'on écrit dans le cache à fréquence CPU plutôt qu'en RAM à fréquence mémoire.
La magie du C , c'est les optimisations. Une fois qu'on a pigé la dizaine d'objets que manipule le compilo, désassemblé un peu de code (en C, l'assembleur se lit bien), on fait des raccourcis de fou, on rassemble le code qui utilise la même data pour empêcher les move's inutiles, on indexe des gros tableaux (pas de hash mais bien des tableaux d'indices) etc...
C# optimisé n'est que 15 à 20% moins rapide que C optimisé à condition de ne pas abuser des appels librairies, accès disques , databases...
Les trucs plus "méchants" (précalculs, calculs partiels, prédictions de branchements, ...) donnent les mêmes gains qu'on soit en C ou en C#. Noter qu'en C#, on optimise en dépliant les boucles mais surtout en évitant de mettre des "new" partout. Donc, on fait de la pré-allocation au démarrage et on évite des syntaxes (géniales par ailleurs) comme
return(new maClasse {truc=1, machin=2});
Petit cadrage : On parle de vulnérabilité logicielle. Dans ce contexte, le code est en cours d'exécution. Il a donc été chargé en mémoire, relogé dans des pages de RAM de sorte que les pointeurs contenus dans le code démarrent bien à l'adresse zéro (anciennement un composant spécial s'en occupait (le PMMU), aujourd'hui cette puce hardware est contenue dans le chipset ou même dans les CPU genre SOC ou APU)
Enfin les segments de code, data heap et data stack sont définis pour cette instance.
Au moment où un programme se fait attaquer, il n'a plus rien en commun avec son code source. C'est du pur binaire, installé en RAM et enregistré par l'OS comme une tâche active.
Bien sûr, la façon de coder va influencer la vulnérabilité du code mais les hackers s'intéressent à la version compilée. Les vulnérabilités sont généralement invisibles dans le source. Il faut connaitre spécifiquement la forme binaire pour fiabiliser le software.
Bon, j'ai essayé de rendre ça compréhensible mais il suffit de retenir que les attaques ont lieu au runtime et non pas au design time.
Je viens de l'essayer en javascript, aucun problème
je vous met au défi de lever une exception ou de provoquer une erreur de calcul avec cette expression.
Je ne comprends pas pourquoi vous insistez sur ce faux problème. Si votre école a appelé ça un undefined behavior, Votre école s'est trompée. Point final.
Personne n'est infaillible.
Cette question n'a rien à voir avec le sujet et n'apporte rien au débat. Néanmoins je vous invite à la tester sur vos compilateurs, vous verrez que ça fonctionne très bien. Je pense qu'on peut même supprimer les espaces et écrire : maj = i+++++i;
Histoire d'obfusquer un peu plus.
Le résultat sera le même
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager