IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire
Pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

Le , par Stéphane le calme

9PARTAGES

13  0 
La National Security Agency (NSA) a publié des conseils pour aider les développeurs et les opérateurs de logiciels à prévenir et à atténuer les problèmes de sécurité de la mémoire logicielle, qui représentent une grande partie des vulnérabilités exploitables. La fiche d'information sur la cybersécurité « Sécurité de la mémoire logicielle » souligne comment les cyberacteurs malveillants peuvent exploiter les problèmes de mauvaise gestion de la mémoire pour accéder à des informations sensibles, promulguer l'exécution de code non autorisé et causer d'autres impacts négatifs.

« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui », a déclaré Neal Ziring, directeur technique de la cybersécurité. « Nous devons utiliser systématiquement des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants ».


La société moderne s'appuie fortement sur l'automatisation basée sur les logiciels, faisant implicitement confiance aux développeurs pour écrire des logiciels qui fonctionnent de la manière attendue et ne peuvent pas être compromis à des fins malveillantes. Alors que les développeurs effectuent souvent des tests rigoureux pour préparer la logique des logiciels à des conditions surprenantes, les vulnérabilités logicielles exploitables sont encore souvent basées sur des problèmes de mémoire. Les exemples incluent le débordement d'une mémoire tampon et l'exploitation des problèmes liés à la façon dont le logiciel alloue et désalloue la mémoire.

Microsoft a révélé lors d'une conférence en 2019 que, de 2006 à 2018, 70 % de leurs vulnérabilités étaient dues à des problèmes de sécurité de la mémoire. Google a également trouvé un pourcentage similaire de vulnérabilités de sécurité de la mémoire sur plusieurs années dans Chrome. Les cyber-acteurs malveillants peuvent exploiter ces vulnérabilités pour l'exécution de code à distance ou d'autres effets indésirables, qui peuvent souvent compromettre un appareil et être la première étape des intrusions réseau à grande échelle. Les langages couramment utilisés, tels que C et C++, offrent une grande liberté et une grande flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le développeur pour effectuer les vérifications nécessaires sur les références mémoire.

De simples erreurs peuvent conduire à des vulnérabilités exploitables basées sur la mémoire. Les outils d'analyse logicielle peuvent détecter de nombreux cas de problèmes de gestion de la mémoire et les options d'environnement d'exploitation peuvent également fournir une certaine protection, mais les protections inhérentes offertes par les langages logiciels sécurisés pour la mémoire peuvent prévenir ou atténuer la plupart des problèmes de gestion de la mémoire.

La NSA recommande d'utiliser un langage sécurisé pour la mémoire lorsque cela est possible. Bien que l'utilisation de protections supplémentaires pour les langages non sécurisés pour la mémoire et l'utilisation de langages sécurisés pour la mémoire n'offrent pas une protection absolue contre les problèmes de mémoire exploitables, elles offrent une protection considérable.

Par conséquent, la communauté logicielle globale du secteur privé, du milieu universitaire et du gouvernement américain a lancé des initiatives visant à orienter la culture du développement logiciel vers l'utilisation de langages sécurisés dans la gestion de la mémoire.


Le problème de la sécurité de la mémoire

La façon dont un programme logiciel gère la mémoire est essentielle pour prévenir de nombreuses vulnérabilités et garantir la robustesse d'un programme. L'exploitation d'une gestion de la mémoire médiocre ou négligente peut permettre à un cyberacteur malveillant d'accomplir des actes néfastes, tels que planter le programme à volonté ou modifier les instructions du programme en cours d'exécution pour faire ce que l'acteur désire. Même des problèmes inexploitables avec la gestion de la mémoire peuvent entraîner des résultats de programme incorrects, une dégradation des performances du programme au fil du temps ou des plantages de programme apparemment aléatoires.

La sécurité de la mémoire est une vaste catégorie de problèmes liés à la façon dont un programme gère la mémoire. Un problème courant est appelé « débordement de tampon », où les données sont accessibles en dehors des limites d'un tableau. D'autres problèmes courants concernent l'allocation de mémoire. Les langages peuvent allouer de nouveaux emplacements de mémoire pendant l'exécution d'un programme, puis désallouer la mémoire, également appelée libération ou libération de la mémoire, plus tard lorsque la mémoire n'est plus nécessaire. Mais si cela n'est pas fait avec soin par le développeur, de la nouvelle mémoire peut être allouée encore et encore au fur et à mesure que le programme s'exécute. Par conséquent, la mémoire n'est pas toujours libérée lorsqu'elle n'est plus nécessaire, ce qui entraîne une fuite de mémoire qui pourrait entraîner le programme à manquer de mémoire disponible.

En raison d'erreurs logiques, les programmes peuvent également tenter d'utiliser la mémoire qui a été libérée, ou même de libérer de la mémoire qui a déjà été libérée. Un autre problème peut survenir lorsque les langages autorisent l'utilisation d'une variable qui n'a pas été initialisée, ce qui fait que la variable utilise la valeur précédemment définie à cet emplacement en mémoire. Enfin, un autre problème difficile est appelé une condition de concurrence. Ce problème peut se produire lorsque les résultats d'un programme dépendent de l'ordre de fonctionnement de deux parties du programme accédant aux mêmes données. Tous ces problèmes de mémoire sont des occurrences beaucoup trop courantes.

En exploitant ces types de problèmes de mémoire, les acteurs malveillants, qui ne sont pas liés par les attentes normales d'utilisation du logiciel, peuvent découvrir qu'ils peuvent entrer des entrées inhabituelles dans le programme, provoquant l'accès, l'écriture, l'allocation ou la désallocation de la mémoire de manière inattendue. Dans certains cas, un acteur malveillant peut exploiter ces erreurs de gestion de la mémoire pour accéder à des informations sensibles, exécuter du code non autorisé ou provoquer d'autres impacts négatifs. Puisqu'il peut falloir beaucoup d'expérimentation avec des entrées inhabituelles pour en trouver une qui provoque une réponse inattendue, les acteurs peuvent utiliser une technique appelée "fuzzing" pour créer de manière aléatoire ou intelligente une multitude de valeurs d'entrée dans le programme jusqu'à ce qu'on en trouve une qui provoque le plantage du programme.

Les progrès des outils et des techniques de fuzzing ont facilité la recherche d'entrées problématiques pour les acteurs malveillants ces dernières années. Une fois qu'un acteur découvre qu'il peut faire planter le programme avec une entrée particulière, il examine le code et travaille pour déterminer ce qu'une entrée spécialement conçue pourrait faire. Dans le pire des cas, une telle entrée pourrait permettre à l'acteur de prendre le contrôle du système sur lequel le programme s'exécute.


Langages sécurisés dans la gestion de la mémoire

L'utilisation d'un langage sécurisé pour la mémoire peut aider à empêcher les programmeurs d'introduire certains types de problèmes liés à la mémoire. La mémoire est gérée automatiquement dans le cadre du langage informatique ; il ne repose pas sur l'ajout de code par le programmeur pour implémenter des protections de mémoire. Le langage institue des protections automatiques en utilisant une combinaison de vérifications au moment de la compilation et de l'exécution. Ces fonctionnalités inhérentes au langage protègent le programmeur contre l'introduction involontaire d'erreurs de gestion de la mémoire. C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

Même avec un langage sécurisé pour la mémoire, la gestion de la mémoire n'est pas entièrement sécurisée pour la mémoire. La plupart des langages de mémoire sécurisés reconnaissent que les logiciels doivent parfois exécuter une fonction de gestion de mémoire non sécurisée pour accomplir certaines tâches. En conséquence, des classes ou des fonctions sont disponibles qui sont reconnues comme non sécurisées pour la mémoire et permettent au développeur d'effectuer une tâche de gestion de la mémoire potentiellement dangereuse. Certains langages exigent que tout ce qui n'est pas sûr en mémoire soit explicitement annoté comme tel pour que le développeur et tous les réviseurs du programme sachent qu'il n'est pas sûr. Les langages sécurisés pour la mémoire peuvent également utiliser des bibliothèques écrites dans des langages non sécurisés pour la mémoire et peuvent donc contenir des fonctionnalités de mémoire non sécurisées. Bien que ces façons d'inclure la mémoire ne soient pas sûres et subvertissent la sécurité inhérente à la mémoire, elles aident à localiser où des problèmes de mémoire pourraient exister, permettant un examen plus approfondi de ces sections de code.

Les langages varient dans leur degré de sécurité de la mémoire institué par des protections et des atténuations inhérentes. Certains langages n'offrent qu'une sécurité de mémoire relativement minimale alors que certains langages sont très stricts et offrent des protections considérables en contrôlant la manière dont la mémoire est allouée, accessible et gérée. Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour obtenir simplement le programme à compiler en raison des vérifications et des protections.

La sécurité de la mémoire peut être coûteuse en matière de performances et de flexibilité. La plupart des langages mémoire sécurisés nécessitent une sorte de récupération de place pour récupérer la mémoire qui a été allouée, mais qui n'est plus nécessaire au programme. Il existe également une surcharge de performances considérable associée à la vérification des limites de chaque accès à la baie qui pourrait potentiellement se trouver en dehors de la baie.

Alternativement, un impact similaire sur les performances peut exister dans un langage non sécurisé en mémoire en raison des vérifications qu'un développeur ajoute au programme pour effectuer la vérification des limites et d'autres protections de gestion de la mémoire. Les coûts supplémentaires liés à l'utilisation de langages non sécurisés pour la mémoire incluent une corruption de mémoire difficile à diagnostiquer et des plantages occasionnels des programmes ainsi que de potentielles exploitations des vulnérabilités d'accès à la mémoire. Il n'est pas anodin de faire passer une infrastructure de développement logiciel mature d'un langage informatique à un autre. Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage.

Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera.

Source : NSA

Et vous ?

Que pensez-vous des conseils de la NSA ? Y en a-t-il que vous appliquez déjà ?
Que pensez-vous du fait que l'agence préconise l'utilisation des langages de programmation sécurisés pour la mémoire comme C#, Go, Java, Ruby, Rust et Swift ?
« Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage. Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera ». Qu'en pensez-vous ? Êtes-vous d'accord avec l'agence ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 23/01/2023 à 20:46
Citation Envoyé par Padget Voir le message
je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets.
Pour la gestion de la mémoire, le C++ offre la possibilité d'utiliser le RAII qui évite les double free et permet aux éventuelles fuites de mémoire de ne pas être plus fréquentes que dans un langage avec ramasse-miettes.

Il y a des développeurs C++ qui sous-utilisent le RAII et introduisent plein de fuites de mémoire, ce qui est un problème culturel autour de l'apprentissage du C++.

Cependant, le C++ n'empêche pas à la compilation les dandling references/pointers/iterators. Par exemple, si on garde une référence vers un élément d'un vecteur, puis que l'on fait un push_back, que ce dernier oblige de déplacer ailleurs en mémoire les éléments du vecteur, puis que l'on essaie d'accéder à ce vers quoi pointe la dandling reference, cela ne provoque pas d'erreur de compilation, contrairement à Rust. Le C++ n'a pas autant de contrôles à la compilation qu'en Rust.

Idem pour le multithreading : le C++ ne fait pas de contrôle à la compilation contre les accès concurrents.

Le C++ n'a pas le borrow checker de Rust. Pour les contrôles à la compilation, ces deux langages ne sont clairement pas au même niveau.
9  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 29/02/2024 à 18:13
Citation Envoyé par commandantFred Voir le message
vous racontez vraiment des cracks sur un site web consacré au dev et que vous seriez blacklistés sur stackoverflow pour bien moins que ça.
https://stackoverflow.com/questions/...c-c-i-i-vs-i-i

D'ailleurs le compilateur peut grogner aussi :

Code : Sélectionner tout
1
2
3
4
5
6
$ gcc -o out a.c -Wall
a.c: In function ‘main’:
a.c:3:17: warning: operation on ‘i’ may be undefined [-Wsequence-point]
    3 |   int j = i++ + ++i ;
      |                 ^~~
Mais sinon sans rire:

Citation Envoyé par commandantFred Voir le message
j'ai fait le test sur un vrai compilateur en ligne.
Qu'est ce qui n'est pas clair dans la définition de "undefined behavior" dans la norme ?
10  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 29/02/2024 à 9:53
Citation Envoyé par commandantFred Voir le message

i++ + ++i

le résultat est 2 i + 1 ; // i est incrémenté deux fois

Il n'y a aucune ambiguïté dans cette expression, par contre elle est difficile à lire et ne donne pas une bonne opinion du développeur qui ferait mieux d'écrire
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.
8  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 29/02/2024 à 13:10
Citation Envoyé par OuftiBoy Voir le message
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.
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.

Citation Envoyé par OuftiBoy Voir le message
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.
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.

Citation Envoyé par OuftiBoy Voir le message
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 à n'utiliser 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é.
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é.
10  2 
Avatar de thamn
Membre averti https://www.developpez.com
Le 23/01/2023 à 22:23
Hebe, il va pas bien Bjarne ou quoi? Il a oublie que C++ a besoin des sanitizers pour ne meme pas arriver au niveau du borrow checker de rust?
Bon, il defend son bout de pain apres, il perd pas le nord, mais bon de la a dire des trucs pareil je sais pas trop..
8  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/02/2024 à 23:03
Citation Envoyé par commandantFred Voir le message
C++ est un compilateur C auquel on applique une surcouche. (Théoriquement, des directives de préprocessing suffisent)
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.

Citation Envoyé par commandantFred Voir le message
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 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.

Citation Envoyé par commandantFred Voir le message
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 ?)
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

Citation Envoyé par OuftiBoy Voir le message
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.
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.

Citation Envoyé par OuftiBoy Voir le message
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.
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.

Citation Envoyé par OuftiBoy Voir le message
Il y a d'ailleurs un langage qui traite déjà ce "problème", et c'est le langage Ada.

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.

Citation Envoyé par OuftiBoy Voir le message
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 ?

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.

Citation Envoyé par OuftiBoy Voir le message
Il vont disparaître d'eux-mêmes en réécrivant tout ?

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

Citation Envoyé par OuftiBoy Voir le message
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.
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.

Citation Envoyé par OuftiBoy Voir le message
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.
...
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.
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 29/02/2024 à 15:52
Citation Envoyé par commandantFred Voir le message
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.
Ton compilateur sort peut-être actuellement le résultat que tu attends, mais c'est une erreur de penser que c'est forcément le résultat qu'il devait te retourner. D'après le standard, le compilateur est libre de faire absolument ce qu'il veux de ce genre d'instruction. Le comportement de cette expression pourrait très bien changer en fonction de la portion du code dans laquelle elle se trouve, des paramètres d'optimisation, de la version du compilateur ou autre.

Comparer avec JavaScript n'a pas de sens vu que sa spécification est différente. Je ne connais bien la spec de JavaScript, mais il me semble que, comme en Java, l'évaluation des éléments d'une expressions est précisément défini. Je ne suis même pas sur que le concept de UB existe en JavaScript.
8  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 29/02/2024 à 19:16
Citation Envoyé par commandantFred Voir le message
Le résultat parle et franchement, seul un gangster sociopathe peut le contester. Ce qui fait le métier de developpeur, ce sont les tests, certainement pas le blabla de jeunes impétueux qui ne citent aucune source ni ne démontrent quoi que ce soit.

C'est la tragédie des codes reposant sur des UD, on peut avoir quelque chose qui marche, jusqu'au jour où ça ne marche plus, parce qu'on a changé de compilateur ou de réglage d'optimisation par exemple. Donc les tests c'est bien, mais malheureusement ça ne démontre pas l'absence de Undefined Behavior.

Citation Envoyé par commandantFred Voir le message
Le résultat : on se trompe tous !

Moi parce que j'ai ajouté 1 à i alors qu'il est incrémenté AVANT exécution de l'expression et qu'il apparait deux fois dans cette même expression, donc il faut ajouter 2 en non 1. La valeur de i résultante est en revanche correcte, (i +=2)

Vous parce que vous prêtez à cette expression un caractère ésotérique alors qu'elle ne pose aucun problème au compilateur. Elle sera très stable et n'aura pas de "pouvoirs magiques"
Notez que je n'ai pas parlé d'ésotérisme mais de comportement non déterminé (Undefined Behavior), c'est a dire des cas certes syntaxiquement valide mais que le programmeur se doit d'éviter dans un code normal. Dans ces cas là, la spécification du C laisse libre cour au compilateur de faire ce qu'il souhaite, y compris des comportements surprenant, car il s'agit de cas qui ne sont pas censé arriver. Il est tout à fait possible (et même probable dans ce cas particulier de UD) que votre compilateur se comporte de manière tout à fait déterministe, mais le standard ne l'y force absolument pas. Le compilateur a tout à fait le droit (et dans certains cas, ne s'en prive pas) de changer de comportement, en fonction des besoins d'optimisation le plus souvent.
Même si votre compilateur est consistant, rien ne garantit qu'il le restera et un autre compilateur peut réagir différemment.

Citation Envoyé par commandantFred Voir le message
Soit vous citez une source bibliographique qui stipule qu'un démon s'est emparé des compilateurs - et qu'on le réveille par l'incantation "i++ + ++i"
Alors comme source bibliographique le standard C++ ça vous va ?
6.5 Expressions, §2
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
Comme ça c'est un peu sec, mais à priori, c'est bien la section concernée. Dans l'expression i++ + ++i la valeur de i est incrémentée deux fois alors que la standard ne garantit le comportement que pour une seule modification. Je ne peux malheureusement lier le document original, il n'est pas en accès libre.

Citation Envoyé par commandantFred Voir le message

Soit vous faites amende honorable et un peu profil bas parce que vous racontez vraiment des cracks sur un site web consacré au dev et que vous seriez blacklistés sur stackoverflow pour bien moins que ça.
En effet je risque tellement de me faire blacklister de stackoverflow que je vous invite à regarder cette question où :
- la personne qui pose la question obtient des résultats variables avec son compilateur (chez moi Gcc et Visual Studio donnent des résultats à la fois différents entre eux et différent de la personne qui pose la question).
- une réponse à 600 votes lui explique que vu ce qu'est un UB ça peut arriver et qu'il n'y a pas de résultat à priori correct défini par le standard.
- d'autre réponses au alentours de 100 votes qui lui expliquent précisément ce qui dans la spécification cause ça.

Je ne vous demanderais pas de faire amande honorable ni profil bas, mais à défaut d’arrêter votre ton accusateur merci.

Citation Envoyé par commandantFred Voir le message
La bible du C s'appelle "The C Programming Language" de Brian W. Kernighan et de Dennis M. Ritchie,
Livre auquel j'ai consacré ma prime jeunesse.
C'est certes l'ouvrage de référence dans l'apprentissage du C et il faisait également office de référence technique dans les années où il n'y avait pas encore de norme. Mais bon la première norme C remonte à il y a 35 ans, c'est clairement l'unique spécification technique reconnue par tous les compilateurs mainstream depuis bien longtemps.

Citation Envoyé par commandantFred Voir le message
Il est mentionné sans ambiguité que l'opérateur unaire "++" situé avant l'opérande, est exécuté avant le code qui l'invoque. Si toutefois, ce même opérateur est situé après l'opérande, l'incrémentation sera exécutée après ce même code.
Ce qui n'est pas faux, mais pas aussi précis que la norme qui introduit entre autre les "sequence points" qui permettent de préciser,le moment oui l'incrémentation se fait dans l'évaluation de l'expression ou la limitation du nombre de modifications d'une variable que j'ai cité plus haut.
Et c'est normal : "The C Programming Language" est un manuel, pas une spécification.

Citation Envoyé par commandantFred Voir le message
J'ai utilisé ce principe toute ma vie sans le moindre bug malgré l'infinité de plateformes sur lesquelles mon code s'exécute encore aujourd'hui
J'ose espérer pour tes collèges que tu n'as pas trop appliqué le principe de modifier plusieurs fois une variable dans une même expression, car en plus d'être un comportement indéterminé, c'est illisible.
8  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 29/02/2024 à 19:51
De mon côté, pour C et C++, je m'appuie souvent sur en.cppreference.com. Les informations y sont bien classées et les pages insistent sur les différences entre les versions du C++ ou celles du C.

Pour le langage C, dans la page sur l'ordre d'évaluation, on peut lire :

If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.
Code C : Sélectionner tout
1
2
3
4
i = ++i + i++; // undefined behavior 
i = i++ + 1; // undefined behavior 
f(++i, ++i); // undefined behavior 
f(i = -1, i = -1); // undefined behavior

La FAQ de en.cppreference.com donne des liens vers les standards payants de C et C++ et les drafs gratuits qui précèdent ces standards.

Dans N2176 (final draft du C17), à la page 55, on peut lire :

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.85)
The grouping of operators and operands is indicated by the syntax.86) Except as specified later, side effects and value computations of subexpressions are unsequenced.87)

La note 85 de bas de page indique :

85)This paragraph renders undefined statement expressions such as
Code C : Sélectionner tout
1
2
i = ++i + 1; 
a[i++] = i;
while allowing
Code C : Sélectionner tout
1
2
i = i + 1; 
a[i] = i;

7  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 05/03/2024 à 16:22
Citation Envoyé par commandantFred Voir le message
Evidemment qu'on teste l'absence de bug !
Ben non, pas "évidemment" du tout. Parce que le test exhaustif ça n'existe pas. Tout ce qu'un test garantit c'est qu'il n'y a pas de bug pour la trace d'exécution exécutée. Des traces d'exécutions il y en a un nombre pas du tout raisonnable dans un programme réaliste.

Citation Envoyé par commandantFred Voir le message
Je ne saurais trop suggérer de ne pas économiser le testing, changer souvent de jeu de tests et même de testeurs(euses).
Ça tombe bien, la citation ne dit pas du tout qu'il ne faut pas tester. Elle dit juste que tester est insuffisant pour garantir l'absence de bugs. C'est même précisément pour ça qu'il a inventé une technique qui s'appelle le weakest precondition calculus (et que d'autres ont inventé pleins d'autres méthodes pour garantir l'absence de certains bugs, comme les procédures de typage par exemple).
8  1