1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    2 006
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 006
    Points : 64 174
    Points
    64 174
    Billets dans le blog
    2

    Par défaut Microsoft rend open source Checked C, une version modifiée du langage C

    Microsoft rend open source Checked C, une version modifiée du langage C
    Conçue pour permettre aux développeurs d’écrire des programmes C plus sécurisés et fiables

    Une bonne partie du système logiciel existant, qu’il s’agisse des systèmes d'exploitation, des navigateurs, des bases de données ou encore des interprètes de langage de programmation, repose sur le langage C ou sur C++, qui lui-même est basé sur C.

    Mais comme l’explique Microsoft dans un billet de blog, il y a certains types d'erreurs de programmation tels que les dépassements de mémoire tampon que les programmeurs peuvent faire pendant qu’ils écrivent des programmes C ou C++ ; lesquelles erreurs pouvant conduire à des failles de sécurité ou des problèmes de fiabilité du logiciel.

    Pour s’attaquer à ce problème et pour permettre aux développeurs d’écrire des programmes C plus sécurisés et plus fiables, Microsoft a donc commencé le développement de Checked C. Il s’agit d’une extension du langage C qui permettra aux développeurs d'ajouter un contrôle statique et dynamique à leurs programmes. Cela, dans le but de détecter ou éviter les erreurs de programmation courantes telles que les dépassements de mémoire tampon entre autres. Checked C pourra donc être utilisé avec des programmes en cours d’exécution ou pendant qu'ils sont en cours d'écriture.

    Microsoft Research rend maintenant son projet open source pour permettre aux chercheurs et aux développeurs de contribuer à la spécification et à l'implémentation du compilateur sur GitHub.

    Ce qu’il est important de noter, c’est que Checked C devrait être compatible avec les programmes C existants, dans la mesure où les changements introduits par le langage open source n’invalident pas le code C existant. Microsoft souligne en effet que les programmes C existants « peuvent être modifiés de manière incrémentielle d’une manière rétrocompatible pour avoir ce contrôle » offert par Checked C. Ainsi, les développeurs n’auront pas besoin de convertir tout leur programme en même temps. Selon leur choix, ils pourront convertir leur code fichier par fichier ou fonction par fonction. Cela en soi donne un grand avantage à Checked C qui pourrait inciter les développeurs à l’adopter une fois qu’il sera officiellement disponible.

    En ce qui concerne la chaine d’outils pour accompagner Checked C, il faut noter que Microsoft travaille également sur l’implémentation d’une version de LLVM/clang modifiée pour supporter l’extension open source du langage C. Checked C et sa spécification sont disponibles sur GitHub.

    Sources : Microsoft Research, Dépôt Checked C, Dépôt LLVM pour Checked C, Dépôt clang pour Checked C

    Et vous ?

    Que pensez-vous de ce nouveau projet open source de Microsoft ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de MagnusMoi
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2013
    Messages
    105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2013
    Messages : 105
    Points : 459
    Points
    459

    Par défaut Et le garbage ?

    Autant j'aime bien Microsoft, autant là où est l'intérêt ?

    Si tu fait du C et que tu as peur des dépassements mémoires, ou de mal gérer la mémoire :
    => tu te fais ta structure pour stocker un pointeur et la taille allouée
    => tu te crées une liste global d'instance de cette structure
    => tu te crées une fonction "find" sur une liste de cette structure pour trouver l'index d'un pointeur
    => tu te crées une fonction "getsizeof" appelant celle "find" pour obtenir la taille alloué à un pointeur
    => tu te crées une fonction "Mon_malloc" appelant malloc et stockant le pointeur dans une instance de structure, elle même mise dans la liste globale
    => tu te crées une fonction "Is_alloc" appelant ta fonction "find" sur la liste global, retournant 0 ou 1
    => tu te crées une fonction "Mon_free" appelant ta fonction "find" sur la liste global, et qui si il trouve le pointeur, le retire (retire la structure le contenant) de la liste globale, puis le détruit avec "free"
    => tu te crées une fonction "clear_all" appelant qui supprime tous les pointeurs de la liste global (évidemment, on ne l'utilise que en fin de programme !!!)
    Du coup quand tu alloues ou veux vérifier un pointeur pas de soucie !
    Est-ce long à coder et mettre en place ?
    nope !
    Et puis-je le mettre dans une bibliothèque ?
    Yep !

    So what ?

    Just do it yourself !
    True Story Bro

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Programmeur / Formateur C/C++
    Inscrit en
    juillet 2014
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Programmeur / Formateur C/C++

    Informations forums :
    Inscription : juillet 2014
    Messages : 58
    Points : 38
    Points
    38

    Par défaut

    Autant C est beau que Microsoft est laid
    Au risque de me faire ésharpé !

  4. #4
    Membre éclairé
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    283
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 283
    Points : 825
    Points
    825

    Par défaut

    Citation Envoyé par MagnusMoi Voir le message
    Autant j'aime bien Microsoft, autant là où est l'intérêt ?

    Si tu fait du C et que tu as peur des dépassements mémoires, ou de mal gérer la mémoire :
    => tu te fais ta structure pour stocker un pointeur et la taille allouée
    => tu te crées une liste global d'instance de cette structure
    => tu te crées une fonction "find" sur une liste de cette structure pour trouver l'index d'un pointeur
    => tu te crées une fonction "getsizeof" appelant celle "find" pour obtenir la taille alloué à un pointeur
    => tu te crées une fonction "Mon_malloc" appelant malloc et stockant le pointeur dans une instance de structure, elle même mise dans la liste globale
    => tu te crées une fonction "Is_alloc" appelant ta fonction "find" sur la liste global, retournant 0 ou 1
    => tu te crées une fonction "Mon_free" appelant ta fonction "find" sur la liste global, et qui si il trouve le pointeur, le retire (retire la structure le contenant) de la liste globale, puis le détruit avec "free"
    => tu te crées une fonction "clear_all" appelant qui supprime tous les pointeurs de la liste global (évidemment, on ne l'utilise que en fin de programme !!!)
    Du coup quand tu alloues ou veux vérifier un pointeur pas de soucie !
    Est-ce long à coder et mettre en place ?
    nope !
    Et puis-je le mettre dans une bibliothèque ?
    Yep !

    So what ?

    Just do it yourself !
    Ça, ça détecte les fuites, mais pas les corruptions, qui dans certains cas pourraient être détectées facilement à la compilation (genre dans le cas d'un tableau de taille statique; Java le fait d'ailleurs).

  5. #5
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 676
    Points : 8 878
    Points
    8 878

    Par défaut

    Citation Envoyé par MagnusMoi Voir le message
    So what ?

    Just do it yourself !
    Si c’était aussi simple que ça ça fait longtemps que les erreur mémoires en C auraient disparu, si on veut vraiment sécuriser le C il faut faire bien plus. Y'a qu'a voir tous les mécanismes qu'a du introduire le langage Rust pour arriver a faire ça sans Garbage Collector.
    Je suis curieux de voir comment Microsoft compte s'y prendre en restant sur une base aussi peut adaptée à la sécurité que le C. J'ai pas encore lu les specs (saleté de format Latex), mais j'ai l'impression que ça va être bien loin de ce que propose Rust.

    Citation Envoyé par Ph. Marechal Voir le message
    Autant C est beau
    On va dire que l'amour est aveugle alors.

  6. #6
    Nouveau membre du Club
    Homme Profil pro
    Programmeur / Formateur C/C++
    Inscrit en
    juillet 2014
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Programmeur / Formateur C/C++

    Informations forums :
    Inscription : juillet 2014
    Messages : 58
    Points : 38
    Points
    38

    Par défaut

    "...il y a certains types d'erreurs de programmation tels que les dépassements de mémoire tampon que les programmeurs peuvent faire pendant qu’ils écrivent des programmes C..." : autant apprendre à bien utiliser C ainsi qu'un bon compilateur / débogueur, c'est une tâche passionnante que d'apprendre à corriger ses erreurs !
    Chaque multinationale veut créer son propre petit langage / framework ou autre machine virtuelle, curieusement elles utilisent C pour ce faire
    C est un langage magnifique par ses performances et la liberté qu'il offre et valgrind est un vieux copain.

  7. #7
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 676
    Points : 8 878
    Points
    8 878

    Par défaut

    Citation Envoyé par Ph. Marechal Voir le message
    "...il y a certains types d'erreurs de programmation tels que les dépassements de mémoire tampon que les programmeurs peuvent faire pendant qu’ils écrivent des programmes C..." : autant apprendre à bien utiliser C ainsi qu'un bon compilateur / débogueur, c'est une tâche passionnante que d'apprendre à corriger ses erreurs !
    C'est peut-être passionnant a déboguer pour toi, mais c'est surtout un risque de comportements anormaux, ou même de failles de sécurité, si ça n'est pas détecté. Et dire "Y'a qu'a bien faire", c'est bien beau, mais tant que les humains seront faillibles, ça n'est clairement pas la solution.
    C'est quelque chose qui peux parfois être très vicieux et même les meilleurs peuvent se faire avoir.

    Citation Envoyé par Ph. Marechal Voir le message
    Chaque multinationale veut créer son propre petit langage / framework ou autre machine virtuelle, curieusement elles utilisent C pour ce faire
    Ce n'est plus systématique.
    Par exemple le compilateur Go est maintenant entièrement écrit en Go. Le compilateur Rust était en OCaml avant d'être réécrit en Rust avec une base LLVM (en C++)

    Citation Envoyé par Ph. Marechal Voir le message
    C est un langage magnifique par ses performances et la liberté qu'il offre et valgrind est un vieux copain.
    C'est tout le problème du C. Il est tellement omniprésent qu'il est systématiquement utilisé pour le bas niveau malgré ses défauts, parce que la plupart des gens qui font du bas niveau ne connaissent que ça, ce qui entretient son omniprésence.
    Du coup plutôt que d’empêcher les erreurs en amont, on accumule les outils permettant de limiter la casse.

  8. #8
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2015
    Messages
    1 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2015
    Messages : 1 014
    Points : 2 161
    Points
    2 161

    Par défaut

    Pour un développeur java qui n'a pas touché au C depuis la L2 de fac (et encore, une fac de physique ), et qui n'a pas la moindre idée des problématiques de gestion de la mémoire, vous pouvez résumer les difficultés du C ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  9. #9
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    26 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 26 761
    Points : 39 297
    Points
    39 297

    Par défaut

    Et pendant ce temps-là, on attend toujours C99, sans parler de C11...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  10. #10
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 676
    Points : 8 878
    Points
    8 878

    Par défaut

    Citation Envoyé par Grogro Voir le message
    Pour un développeur java qui n'a pas touché au C depuis la L2 de fac (et encore, une fac de physique ), et qui n'a pas la moindre idée des problématiques de gestion de la mémoire, vous pouvez résumer les difficultés du C ?
    Ca va être dur de faire un cours de sécurité en un message mais le principaux problèmes qui me viennent en tête sont:
    • Le dépassement de mémoire : En gros dans un tableau de taille 10, on essaie d'écrire le 11eme élément. On va donc écrire dans une zone mémoire située après le tableau qui n'a rien a voir et qui si ça ne plante pas va probablement provoquer des comportement incohérents du programme qui peuvent mener a une faille de sécurité.
    • L'utilisation après libération : Quand on a besoin de mémoire on la réserve et on obtient un pointeur vers la zone mémoire. Une fois libérée cette mémoire peut-être ré-allouée ailleurs. Donc si on continue à utiliser l'ancien pointeur on va avoir deux pointeurs qui pointent vers une même zone pour faire des choses qui n'ont rien à voir. La encore le programme devient imprévisible et des faille sont souvent a la clé
    • La double libération. Quand on essaie de libérer une zone mémoire déjà libérée, on a au mieux un plantage mais il peut se passer tout un tas de chose bizarres. Par exemple on peut désallouer la zone mémoire qui avait été ré-allouée entre temps, provoquant une utilisation après libération à l'autre bout du programme.
    • Les comportements non définis. De nombreux points de la spécification du C sont volontairement non définis et laissent le compilateur libre de faire ce qu'il veux. Il vaut mieux les éviter au risque de se retrouver avec des comportements imprévisibles suivant les envies d'optimisation du compilateur.

    Certaines de ces erreurs peuvent te paraître grossières quand on les explique simplement, mais je te garantis que dans les programmes complexes, il est bien plus facile qu'on ne le croit de les faire sans que ce soit évident a détecter.

  11. #11
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    616
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 616
    Points : 17 072
    Points
    17 072

    Par défaut Microsoft publie un document décrivant les progrès réalisés dans le cadre du projet Checked C

    Microsoft publie un document décrivant les progrès réalisés dans le cadre du projet Checked C
    Visant à rendre le développement sous C plus sûr

    Une bonne partie de l’environnement logiciel existant (navigateurs, bases de données, interprètes de langage de programmation ou systèmes d’exploitation pour ne citer que ceux-là) repose toujours sur le C, un langage de programmation qui a fait son apparition dans les années 70 et qui est à la base de nombreux autres langages tels que le C++ et le C #.

    En 2016, Microsoft a lancé une initiative qui, à terme, devait permettre de rendre le développement sous C plus fiable et plus sûr. Baptisé Checked C, cette initiative visait l’introduction d’une nouvelle extension du langage C qui serait rétro compatible et intègrerait des outils de vérifications et des garde-fous afin de limiter la survenue d’erreurs durant les phases de développement et l’apparition ultérieure de bogues et/ou de vulnérabilités au sein des logiciels codés en C.

    Microsoft a récemment publié un document décrivant les progrès réalisés par ses équipes dans le cadre de son projet visant à rendre le développement sous C plus fiable et plus sûr. Il sera présenté lors de la conférence sur le développent et la cybersécurité de l’IEEE (IEEE SecDev) qui sera organisé du 30 septembre au 2 octobre 2018 à Cambridge, aux États-Unis.

    Ce document confirme que Checked C permettra aux développeurs d’ajouter un contrôle statique et dynamique à leurs programmes pour les aider à déceler plus rapidement ou à éviter les erreurs de programmation courantes telles que le « buffer overflow » (les dépassements de mémoire tampon) ou les erreurs de conversion de type d’objets.

    Il révèle ainsi qu’afin de garantir un meilleur contrôle sur les pointeurs, Checked C utilise une forme de pointeur vérifié, dont les accès peuvent être vérifiés statiquement ou dynamiquement. Checked C a été conçu comme une extension du compilateur Clang/LLVM et devrait introduire les notions de « checked region » et « bounds-safe interfaces ». Signalons au passage que les programmes codés en C pourront être convertis vers Checked C de manière progressive, fonction par fonction, grâce à la conversion incrémentielle.

    Checked C proposera aussi des outils permettant de procéder à des vérifications durant l’écriture du code source, avant que celui-ci ne soit compilé et exécuté.

    Source : Checked C (PDF)

    Et vous ?

    Qu’en pensez-vous ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  12. #12
    Membre actif
    Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 24
    Points : 207
    Points
    207

    Par défaut

    Une bonne façon de résoudre une grande partie des problèmes serait de:
    - ajouter un typage "array of" comme il y avait en pascal pour retirer l'ambiguïté entre pointeur sur un élément et pointeur sur tableau
    - rajouter les références pour diminuer les pointeurs nuls
    - retirer tous les 'cast' implicites

  13. #13
    Membre expérimenté
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 311
    Points : 1 384
    Points
    1 384

    Par défaut

    Citation Envoyé par pboulanger Voir le message
    Une bonne façon de résoudre une grande partie des problèmes serait de:
    - ajouter un typage "array of" comme il y avait en pascal pour retirer l'ambiguïté entre pointeur sur un élément et pointeur sur tableau
    - rajouter les références pour diminuer les pointeurs nuls
    - retirer tous les 'cast' implicites
    En gros rapprocher le C du Pascal... Typage fort, Pointeurs typés, etc...

  14. #14
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 552
    Points : 7 200
    Points
    7 200

    Par défaut

    J'en pense que ce n'est pas forcément utile.
    On trouve tout le confort nécessaire avec des outils d'analyse statique ou dynamique.
    Un coup de Valgrind et de Sonar suffit par exemple à détecter toutes les erreurs citées par Uther.
    Dans une chaîne de développement je ne vois pas pourquoi on aurait l'absence de ce genre d'outil (ce serait comme dire qu'on n'utilise pas de gestion de conf), du coup pourquoi vouloir combler un trou qui est déjà comblé ?
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  15. #15
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    782
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 782
    Points : 2 320
    Points
    2 320

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Un coup de Valgrind et de Sonar suffit par exemple à détecter toutes les erreurs citées par Uther.
    Dans une chaîne de développement je ne vois pas pourquoi on aurait l'absence de ce genre d'outil (ce serait comme dire qu'on n'utilise pas de gestion de conf), du coup pourquoi vouloir combler un trou qui est déjà comblé ?
    Bien que je sois d'accord avec la necessité de ces outils, le fait est qu'ils restent des rustines correctives nécessaires pour éviter des erreurs dues, selons les points de vues, soit à des défauts du langages, soit à l'incompétence du développeur.

    Selon moi la performance du C vient en partie grâce à ces défauts et utiliser ces outils est selon moi la bonne solution.

    Il n’empêche qu'ils ne corrigent pas les problèmes cités.


    Pour moi si vous voulez éviter ce genre de problème à la compilation, il ne faut pas choisir le C, mais plus l'ADA par exemple...

  16. #16
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 552
    Points : 7 200
    Points
    7 200

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    Pour moi si vous voulez éviter ce genre de problème à la compilation, il ne faut pas choisir le C, mais plus l'ADA par exemple...
    Pour moi l'intérêt n'est pas d'éviter ce genre de problème à la compilation mais à la livraison.
    Après toutes les méthodes sont bonnes avec certaines plus coûteuses que d'autres.
    Mais introduire un nouveau langage ne supprimera pas les outils que j'ai cité, donc c'est redondant pour moi.
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  17. #17
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 696
    Points : 3 075
    Points
    3 075

    Par défaut

    Aujourd'hui, les intérêts du langage C sont qu'il est performant, interopérable, portable et stable. Si le langage C n'évolue quasiment pas, c'est pour rester portable et stable.

    Si on veut un langage rétrocompatible avec le C, performant et qui évolue, ce langage existe déjà : c'est le C++.
    À quelques rares incompatibilités près (par exemple, en C, void* est implicitement convertible en tout type de pointeur), du code écrit en C compile en C++. Donc il n'y a pas beaucoup d'efforts à fournir pour que du code C compile à la fois en C et en C++.
    Il existe bien quelques rares fonctionnalités du C qui n'existent pas en C++ officiel, par exemple le mot-clef restrict de C99. Mais, si on utilise un compilateur comme GCC, on peut choisir d'écrire dans un C++ étendu avec les quelques fonctionnalités spécifiques au C.
    Toujours avec GCC, on peut supprimer l'overhead ajouté par le C++, par exemple avec des options comme -fno-exceptions (pour désactiver la gestion des exceptions).
    Une fois qu'on a un code qui compile à la fois en C et en C++, on peut migrer progressivement vers le C++.

    Sur la page Extension overview du Wiki sur le Checked C, j'ai regardé rapidement les liens donnés par la section More information et je ne vois pas de vrai intérêt du Checked C par rapport au C++ : parmi ce que j'ai lu, toutes les fonctionnalités présentées en Checked C peuvent être implémentées sous la forme d'une simple bibliothèque C++ grâce aux templates et à la surchage d'opérateurs.

    Donc j'ai l'impression que le seul intérêt du Checked C est de ne pas avoir à apprendre le C++.

    À part ça, si on veut faire de la programmation bas niveau avec de bons contrôles à la compilation, il faut se tourner vers Rust. Mais du code écrit en C ne compilera pas en Rust. Il faudra alors interfacer du Rust et du C.

    Citation Envoyé par AoCannaille Voir le message
    Selon moi la performance du C vient en partie grâce à ces défauts et utiliser ces outils est selon moi la bonne solution.
    Je t'invite à jeter un œil au langage Rust. Tu constateras que la majorité des défauts du C viennent plus d'un problème de conception que d'un besoin de performance.
    Pour être honnête, il y a bien des cas en Rust où il faut choisir entre la performance et la robustesse. Mais il y a beaucoup de cas où on peut bénéficier des deux à la fois.

  18. #18
    Membre actif
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    139
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 139
    Points : 298
    Points
    298

    Par défaut

    Y a t il une option de compilation, comme il y avait en Turbo Pascal (eh oui ça date ) qui permette de forcer lors de l'accès à un tableau si l'indice est bien dans le tableau ? de base, si ma mémoire est bonne, le pascal faisait une vérification que l'on pouvait ensuite supprimer via une option.
    Mais en C je n'ai pas trouvé cela.

    Après c'est sûr qu'il faudrait peut être passer tout simplement en C++

  19. #19
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 696
    Points : 3 075
    Points
    3 075

    Par défaut

    Citation Envoyé par archqt Voir le message
    Y a t il une option de compilation, comme il y avait en Turbo Pascal (eh oui ça date ) qui permette de forcer lors de l'accès à un tableau si l'indice est bien dans le tableau ?
    En C, avec GCC tout seul, je ne pense pas.
    Par contre, si on travaille avec des fonctions personnalisées, on peut faire de la compilation conditionnelle pour décider si les contrôles de ces fonctions sont actifs.

    En complément de mon message précédent, en C++, on peut bricoler ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    #include <cassert>
    #include <exception> // std::terminate
    
    #if defined(NDEBUG) && defined(CHECK)
    # define MY_ASSERT(cond)\
    	if(cond)\
    		static_cast<void>(0);\
    	else\
    		std::terminate() // code bourrin pour l'exemple
    #elif defined(NDEBUG)
    # define MY_ASSERT(cond) static_cast<void>(0)
    #else
    # define MY_ASSERT(cond) assert(cond)
    #endif
    
    template<class T, size_t Size>
    class MyArray
    {
    public:
    	T& operator[](size_t index) {
    		MY_ASSERT(index < Size);
    		return m_values[index];
    	}
    
    	T const& operator[](size_t index) const {
    		MY_ASSERT(index < Size);
    		return m_values[index];
    	}
    
    	template<size_t Index>
    	T& get() {
    		static_assert(Index < Size);
    		return m_values[Index];
    	}
    
    	template<size_t Index>
    	T const& get() const {
    		static_assert(Index < Size);
    		return m_values[Index];
    	}
    
    private:
    	T m_values[Size];
    };
    
    int main()
    {
    	MyArray<int, 2> myArray; // tableau de 2 éléments de type int
    	myArray.get<0>() = 10; // contrôle l'indice à la compilation : OK
    	myArray[1] = 11; // contrôle OK à l'exécution (si les contrôles sont actifs)
    //	myArray.get<2>() = 12; // erreur de compilation
    	myArray[2] = 12; // signale une erreur à l'exécution (si les contrôles sont actifs)
    	return 0;
    }
    Dans mon exemple, le modèle de fonction get prend en argument de modèle un indice qui doit être connu à la compilation et signale une erreur de compilation si cet indice est en dehors des bornes.
    L'opérateur avec des crochets, lui, prend en argument un indice qui peut être inconnu à la compilation. Il effectue un contrôle à l'exécution, ou pas, selon le comportement de la macro MY_ASSERT.
    Le comportement de la macro MY_ASSERT dépend si les macros NDEBUG et CHECK sont définies. C'est dans les options de compilation que l'on choisit si on définit NDEBUG et si on définit CHECK.

    Remarque 1 : à la place de ma macro illustrative MY_ASSERT, il existe déjà BOOST_ASSERT (de la bibliothèque Boost) qui est meilleure, mais un peu plus compliquée à expliquer.

    Remarque 2 : en C++20, MY_ASSERT et BOOST_ASSERT seront obsolètes, car on aura enfin une manière standardisée de faire de la programmation par contrats. Par exemple, les préconditions seront exprimées avec un attribut expects.
    Le comportement adopté par le programme en cas de violation de contrat devrait être personnalisable.

  20. #20
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 676
    Points : 8 878
    Points
    8 878

    Par défaut

    Citation Envoyé par Christian Olivier Voir le message
    Qu’en pensez-vous ?
    J'ai regardé l'article en lien, visiblement ils ne se sont penché que sur le problème des buffer overflow, ce qui est très très loin d'être suffisant. Au niveau de la sécurité, ça reste a des année lumière de ce que proposent Rust et Ada. Le soucis, c'est que C est un langage conçu sans aucune idée de sécurité, vouloir le sécuriser en restant compatible ressemble pour moi a une mission impossible.
    L’intérêt de sécuriser un langage est de fournir des garanties, si les anciens mécanisme pas sûrs sont gardés à l'identique, ils vont juste se retrouver dans la situation de C++.

    Citation Envoyé par transgohan Voir le message
    Un coup de Valgrind et de Sonar suffit par exemple à détecter toutes les erreurs citées par Uther.
    Dans une chaîne de développement je ne vois pas pourquoi on aurait l'absence de ce genre d'outil (ce serait comme dire qu'on n'utilise pas de gestion de conf), du coup pourquoi vouloir combler un trou qui est déjà comblé ?
    Les outils d'analyse dynamique sont très utiles mais c'est loin d'être aussi complet que ce que permet l'analyse statique d'un langage qui s'y prête bien comme Rust (Ada aussi, mais je vais plutôt parler de Rust que je connais mieux).
    Ces outils se contentent de détecter les cas d'erreurs quand ils se produisent. C'est un grand progrès par rapport a pas d'analyse du tout, mais ils ne peuvent pas garantir que tous les cas d'utilisation ont été couverts.

    Citation Envoyé par AoCannaille Voir le message
    Selon moi la performance du C vient en partie grâce à ces défauts
    C'est pas tout a fait vrai si on regarde du coté de Rust qui arrive a lier performance et sécurité.

    Citation Envoyé par transgohan Voir le message
    Pour moi l'intérêt n'est pas d'éviter ce genre de problème à la compilation mais à la livraison.
    Après toutes les méthodes sont bonnes avec certaines plus coûteuses que d'autres.
    Mais introduire un nouveau langage ne supprimera pas les outils que j'ai cité, donc c'est redondant pour moi.
    Non toute les méthodes ne sont pas "aussi" bonnes que les autres. Une bonne analyse dynamique n'est pas parfaite et peut laisser passer des cas d'erreur. Avec une bonne analyse statique sur un langage qui s'y prete bien, on peut garantir que certaines erreurs n'arrivent jamais.
    Les outils que tu as cité restent utiles en Rust principalement parce qu'il permet de s'interfacer avec du code C et qu'il existe un mécanisme qui permet d'ignorer localement certaines sécurités. Mais le langage de base garantit que les erreurs de sécurité mémoire ne peuvent arriver.

Discussions similaires

  1. Réponses: 4
    Dernier message: 29/05/2015, 11h22
  2. Le framework open source Django sort en version 1.7
    Par Hinault Romaric dans le forum Django
    Réponses: 9
    Dernier message: 13/09/2014, 11h31
  3. Facebook rend open source Ringmark
    Par Hinault Romaric dans le forum Général Conception Web
    Réponses: 2
    Dernier message: 16/04/2012, 16h02
  4. Réponses: 16
    Dernier message: 09/06/2010, 11h20
  5. Réponses: 4
    Dernier message: 24/07/2009, 14h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo