Comment pouvons-nous être certains que les composants inférieurs de la programmation informatique comme les compilateurs, les assembleurs, les instructions machine, etc. sont sans défaut?
Comme nous dépendons de plus en plus de l'informatique, y compris des tâches très critiques de la vie quotidienne, je me demandais simplement comment ces composants vitaux sont testés.
Plus techniquement, comment les compilateurs et assembleurs sont-ils testés? (Je suppose que cela concerne le problème d'arrêt !!)
Vous ne pouvez pas en être certain, mais vous supposez qu'ils le sont, jusqu'à ce que vous découvriez qu'ils ne le sont pas. Il y a eu beaucoup de bugs dans les compilateurs et le matériel au fil des ans.
La façon dont ceux-ci sont testés, par exemple un compilateur, est qu'ils sont définis de manière très étroite et rigide, soigneusement écrits, puis testés avec une suite de tests énorme pour vérifier l'exactitude. Ajoutez à cela la large base d'utilisateurs d'un compilateur, et plus de bugs seront détectés et signalés. Une application de planification de rendez-vous chez le dentiste, comparativement, a beaucoup moins d'utilisateurs, et encore moins qui sont capables de détecter des défauts.
SQLite se compose d'environ 73k lignes de code, tandis que sa suite de tests se compose d'environ 91378k lignes de code, plus de 1250 fois celle de SQLite lui-même. Je m'attends à ce que les compilateurs et autres outils de base aient des ratios similaires. Les processeurs d'aujourd'hui sont essentiellement conçus avec des logiciels, en utilisant des langages de description matérielle comme Verilog ou VHDL, et ceux-ci ont également des tests logiciels exécutés sur eux, ainsi que des broches spécialisées IO pour exécuter des auto-tests au point de fabrication.
En fin de compte, c'est un jeu de probabilité, et des tests répétés et couvrant largement vous permettent de pousser la probabilité de défauts à un niveau suffisamment bas, comme un autre projet logiciel.
En termes simples:
- Vous ne pouvez pas.
- Les compilateurs et les interprètes sont testés à l'unité comme tout autre logiciel (professionnel).
- Un test réussi ne signifie pas qu'un programme est exempt de bogues, cela signifie seulement qu'aucun bogue n'a été détecté.
- Une large base d'utilisateurs utilisant le compilateur pendant une longue période est un joli indicateur qu'il a très peu de bugs, car les utilisateurs testent généralement les cas auxquels les concepteurs n'ont pas pensé.
- Être open source est également un bon indicateur. "Étant donné suffisamment de globes oculaires, tous les bogues sont superficiels ... Compte tenu d'une base de bêta-testeur et de co-développeur suffisamment grande, presque tous les problèmes seront caractérisés rapidement et le correctif sera évident pour quelqu'un." . Un compilateur de source fermée peut avoir des bogues qui surviennent à des moments très précis ou qui génèrent un code machine moins qu'optimal et l'entreprise derrière lui pourrait tout simplement ne pas révéler leur existence et lui donner une très faible priorité dans la feuille de route du produit.
Résultat:
Je dirais optez pour OOP ( [~ # ~] o [~ # ~] ld, [~ # ~] o [~ # ~] stylet et [~ # ~] p [~ # ~] opular). Je viens de inventer cet acronyme.
C'est des tortues tout le long.
Rien est certain. Vous n'avez pas d'autre choix que de vous contenter de notes de confiance.
Vous pouvez le considérer comme une pile: mathématiques> physique> matériel> micrologiciel> système d'exploitation> assembleur/compilateur/etc.
À chaque niveau, vous disposez de tests que vous pouvez effectuer pour améliorer votre indice de confiance. Certains de ces tests ont la qualité de preuves formelles, certains sont basés sur l'observation, la plupart sont une combinaison des deux.
La partie délicate consiste à démêler la récursivité dans certains de ces tests parce que nous utilisons des programmes pour faire des preuves et des analyses d'observation maintenant où il est devenu trop difficile de le faire à la main.
En fin de compte, la réponse est que vous essayez tout ce à quoi vous pouvez penser. Analyse statique, fuzzing, simulation, fonctionnement avec des entrées extrêmes sélectionnées de manière ciblée ou des entrées aléatoires, exécution/mappage de chaque chemin de contrôle, preuves formelles, etc. Fondamentalement, votre objectif dans les tests doit toujours être de tout faire pour prouver que votre produit puce/programme) ne fonctionne pas comme prévu. Si vous faites un véritable effort et échouez encore, vous êtes autorisé à améliorer votre indice de confiance dans l'exactitude de votre produit.
Le test est au mieux un processus de semi-décision, ce qui signifie qu'étant donné qu'il y a un bogue, vous finirez par le trouver, mais vous ne pouvez jamais être sûr que vous les avez tous trouvés. Même avec des logiciels officiellement vérifiés, vous vous fiez toujours à la physique, aux outils utilisés pour faire les preuves formelles, et que la chose que vous avez prouvée est nécessaire et suffisante pour que votre programme fasse ce qui est (souvent subjectivement) "prévu". Sans parler de tous les autres composants que vous utilisez qui n'ont pas de preuves formelles.
C'est une question "dangereuse" pour les nouveaux développeurs dans la mesure où ils vont commencer à blâmer leurs outils au lieu de leur code (déjà là, fait cela, vu trop de gens le faire). Bien qu'il y ait des bogues dans les compilateurs, les environnements d'exécution, le système d'exploitation, etc., les développeurs doivent être réalistes et s'en souvenir, jusqu'à ce qu'il y ait des preuves et des tests unitaires démontrant le contraire, le bogue est dans votre code.
En plus de 25 ans de programmation principalement en C, C++ et Java j'ai trouvé:
- deux bogues dus à un bogue du compilateur (gcc et SunOS C)
- environ une fois par an ou deux un bug dû à un Java problème JVM (généralement lié à la consommation de mémoire/à la récupération de place)
- environ une fois par mois ou deux un bogue dans une bibliothèque, qui est fréquemment corrigé en utilisant la dernière version ou en revenant à la version précédente de la bibliothèque
Tous les autres bogues sont directement liés à un bogue ou, plus fréquemment, à un manque de compréhension du fonctionnement d'une bibliothèque. Parfois, ce qui semble être un bogue est dû à une incompatibilité, par exemple comment la structure de classe Java a changé et a cassé certaines bibliothèques AOP.
Je pense qu'un point intéressant ici est que la grande majorité des licences de logiciels commerciaux (et en fait de logiciels open source) spécifient spécifiquement que vous ne pouvez pas faire confiance au logiciel.
LE LOGICIEL IS FOURNI "TEL QUEL", SANS GARANTIE D'AUCUNE SORTE, EXPRESS OR IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN OBJECTIF PARTICULIER ET NON-CONTREFAÇON.
De l'accord de licence Microsoft Word
. À l'exception de la garantie limitée et dans toute la mesure permise par la loi applicable, Microsoft et ses fournisseurs fournissent le logiciel et les services de support (le cas échéant) COMME IS ET AVEC TOUS LES DÉFAUTS, et déclinent par la présente tout autre garanties et conditions, qu'elles soient expresses, implicites ou statutaires, y compris, mais sans s'y limiter, les garanties, obligations ou conditions implicites (le cas échéant) de qualité marchande, d'adéquation à un usage particulier, de fiabilité ou de disponibilité, d'exactitude ou d'exhaustivité des réponses , des résultats, des efforts de travail, du manque de virus et du manque de négligence, tous en ce qui concerne le logiciel, et la fourniture ou le défaut de fournir un support ou d'autres services, informations, logiciels et contenus associés via le logiciel ou résultant autrement de l'utilisation du Logiciel.
En substance, cette phrase de la licence dans presque tous les logiciels que vous utilisez vous indique spécifiquement que vous ne pouvez pas faire confiance au logiciel et encore moins au compilateur utilisé.
Le logiciel est comme une théorie scientifique, il est censé fonctionner comme spécifié jusqu'à ce qu'il ne fonctionne pas.
En tant que rédacteur de compilateur pour un langage mathématique *, d'après mon expérience, je peux dire en théorie que vous ne pouvez pas. Et certains des bugs donnent juste des résultats erronés comme (à partir de ma liste de honte) calculant 6/3*2 À partir de la bonne 6/(3*2) et sortie 1 sans planter ou donner des erreurs de compilation absurdes.
Mais à mon humble avis, de nombreux compilateurs n'ont pas autant de bogues que les autres logiciels car:
- Écrire des tests unitaires est facile. Chaque instruction est une unité et vous pouvez écrire des tests aussi simples que:
test_unit("2+(-2)*(-2+1)*3+1",9); - Un programme est une combinaison d'instructions et pour que tout programme génère le résultat correct, chaque instruction individuelle doit donner le résultat correct (la plupart du temps). Il est donc très peu probable qu'il y ait des bogues pendant que le programme donne le résultat correct.
- À mesure que la taille et le nombre de programmes écrits augmentent, la probabilité d'attraper des bogues augmente considérablement.
Pour les assembleurs, les instructions de la machine, etc., ce qui précède est également valable; d'autre part, la vérification et la validation dans la conception et la production de puces ont des processus beaucoup plus stricts car c'est une énorme affaire: Automatisation de la conception électronique .
Avant de passer en production, chaque CPU doit être testé rigoureusement car chaque bogue coûte près de quelques millions de dollars: il y a d'énormes coûts de production non récurrents dans la production de puces. Les entreprises dépensent donc beaucoup d'argent et écrivent beaucoup de code de simulation pour leur conception avant de commencer la production, bien que cela ne donne pas une garantie à 100% - par exemple: le bogue Pentium FDIV.
En bref, il est très peu probable qu'il y ait de graves bogues dans les compilateurs, les codes machine, etc.
Sans défaut? Ils ne sont pas. J'ai récemment installé quelques "mises à jour", et il a fallu des mois (et plusieurs sections de code reprogrammées) plus tard avant que mon site ASP.NET ne fonctionne à nouveau correctement, en raison de changements inexpliqués dans le fonctionnement ou l'échec de diverses choses de base.
Cependant, ils sont testés puis utilisés par de nombreuses personnes très intelligentes et soucieuses du détail, qui ont tendance à remarquer et à signaler et à réparer la plupart des choses. Stack Exchange est un excellent exemple (et une amélioration) de la façon dont toutes les personnes utilisant ces outils aident à tester et à analyser le fonctionnement de ces outils incroyablement complexes et de bas niveau, au moins dans la mesure où leur utilisation est pratique.
Mais sans défaut, non. Bien que vous puissiez également voir des personnes sur Stack Exchange obtenir des informations impressionnantes sur les détails des performances et la conformité aux normes et aux bizarreries, il y a toujours des défauts et des imperfections, en particulier lorsque différentes personnes ont des opinions différentes sur ce qu'est une faille.