Les compilateurs et les interprètes peuvent-ils avoir des bogues, et que pouvons-nous (en tant qu'utilisateurs) faire pour les résoudre? [fermé]


28

Si le travail d'un compilateur consiste essentiellement à traduire le code source en code au niveau de la machine, peut-il y avoir un problème dans un compilateur, c'est-à-dire une "traduction" défectueuse?

Il en va de même pour un interprète: peut-il parfois ne pas produire le contenu requis?

Je n'ai pas entendu parler de bugs dans les compilateurs / interprètes, mais existent-ils?


6
en développement, ils existeront très certainement, regardez le bugtracker sur n'importe quel compilateur open source
ratchet freak

7
Je n'ai pas entendu parler de bugs dans les compilateurs / interprètes, mais existent-ils? J'ai trouvé la liste de diffusion des bogues dans le compilateur gcc: gcc.gnu.org/ml/gcc-bugs
FrustratedWithFormsDesigner

47
Ce n'est pas une très bonne question, cela demande juste quelque chose de bon sens.

12
Jusqu'à présent, aucun des commentaires ou réponses ne traite de la probabilité de rencontrer un bogue du compilateur. Assurez-vous d'abord d'exclure les erreurs dans votre propre code.
Dan Pichelman

6
Réponse courte: certainement. Alors que les IDE et les compilateurs sont généralement exercés dans un pouce de leur vie avant de voir le monde extérieur, il y a toujours quelque part un cas de coin qu'un développeur un peu trop intelligent trouvera.
KeithS

Réponses:


51

Oui

Vous avez tendance à les trouver plus dans des langues en développement actif que dans des langues relativement matures (et ne voyez donc pas beaucoup de changements sur une base fréquente). C'est probablement pourquoi la plupart des langues sont publiées à différents «stades» de stabilité. Une version nocturne est beaucoup moins susceptible d'être stable qu'une version candidate , qui est elle-même moins susceptible d'être stable qu'une version entièrement publiée et activement utilisée.

Heureusement, la plupart de ces langues (en particulier celles qui sont open source) auront un système de suivi des bogues public auquel vous pourrez soumettre des rapports.

Dans ma propre expérience, je suis tombé sur un bogue assez obscur mais grave dans Scala sur Windows . J'ai soumis mes conclusions au traqueur de bogues et le problème a été résolu assez rapidement. Dans ce cas, les développeurs du langage ont été assez intelligents pour inclure une note utile dans la sortie du journal des erreurs, suggérant que ce que j'avais rencontré était en fait une erreur de compilation, et ont dit où soumettre le rapport.


J'espère que cela ne vous dérange pas; J'ai ajouté un nouveau paragraphe (en attente d'approbation) que j'ai jugé pertinent. Non seulement un compilateur peut contenir des bogues, mais il peut également contenir du code malveillant.
Andy

@Andy, il semble que l'un des modérateurs l'ait rejeté comme quelque chose qui devrait être un commentaire ou une réponse distincte.
KChaloux

Pas seulement "oui", mais "enfer oui!" :-)
Hellion

C est à la fois mature et développé activement. Il en va de même pour C ++. Java aussi. etc.
djechlin

100

Dans les mots du profane:

Tous les programmes peuvent avoir des bugs.

Les compilateurs sont des programmes.

Ergo, les compilateurs peuvent avoir des bugs.


55
Plus inquiétant: les débogueurs sont des programmes. Par conséquent, les débogueurs ont des bogues.
Daniel Gratzer

19
@jozefg: Alors, comment déboguez-vous le débogueur? Qui regarde les observateurs?
FrustratedWithFormsDesigner

16
@FrustratedWithFormsDesigner Les observateurs, duh.
Jimmy Hoffa

9
@JoelFan Depuis que j'ai écrit "peut avoir", cette exception est couverte. Si vous dites "avoir", vous devez spécifier que vous vous référez uniquement à des programmes non triviaux. En disant "peut avoir", vous n'avez pas à le faire.
Tulains Córdova

8
Les programmes "Hello world" peuvent avoir des bogues s'ils sont conformes à un compilateur bogue.
wtsang02



4

Bien sûr, car les compilateurs sont des logiciels.

En 2005, j'ai eu un échec de code dans un logiciel hautement critique que j'avais écrit pour une grande entreprise. Puisqu'il a littéralement coûté des millions de dollars à la société pour y remédier, ils ont bien sûr lancé une enquête de grande envergure.

Heureusement (de mon point de vue), le problème s'est avéré être un problème de compilation dans Delphi. Dans le bloc try finally, la valeur de retour d'une fonction a été détruite et a donné des résultats absolument aléatoires à l'appelant. Cela a été documenté et reconnu par Borland.

.NET était bien connu pour avoir littéralement des centaines de fuites de mémoire différentes, en particulier dans ses premières implémentations.

Je dirais qu'il n'existe pas de logiciel sans bugless. Les compilateurs ne font pas exception. Cependant, ils sont testés de manière plus approfondie que la plupart des logiciels d'entreprise et sont consommés par des personnes intelligentes, critiques et litigieuses, de sorte que leur bilan a été, dans l'ensemble, plutôt bon.


Il existe un logiciel "officiellement vérifié". Il est mathématiquement prouvé qu'il fonctionne. Parfois, même le code officiellement vérifié comporte des bogues. L'implémentation de tri rapide de l'IIRC Java a été officiellement vérifiée, mais cela ne tenait pas compte des débordements.
David Plumpton

1
Quel était le logiciel? Allez :)
Rocklan

2

Non seulement des bogues, mais aussi des logiciels malveillants délibérés.

Le cheval de Troie «login» implémenté par Brian Kernighan dans le compilateur Unix C d'origine est le plus connu d'entre eux; l'article http://cm.bell-labs.com/who/ken/trust.html a quelques informations à ce sujet.


1
Est-il clair que cela a effectivement été mis en œuvre?
Keith Thompson

C'est un sujet assez intéressant, mais pas du tout lié à cette question.

@delnan je ne suis pas d'accord; au cœur de la question semble être "combien puis-je faire confiance à mon compilateur?"
Andy

1

Oui bien sûr, comme tous les compilateurs de logiciels ont des bogues, par exemple la liste des bogues gcc est ici


0

Oui.

En outre, non seulement avec les compilateurs, mais aussi avec les interpréteurs / débogueurs et tout outil logiciel tiers.

Nous utilisons actuellement des logiciels tiers et rencontrons certains problèmes. Parfois, ils nous remercient d'avoir trouvé et signalé un bug. :)

Certains d'entre eux ont également des fuites de mémoire, ce qui entraîne un crash. La question importante ici pourrait être, comment déterminer si l'outil tiers ou le compilateur a des bogues pour que votre application fonctionne correctement?


Votre question importante ramènera ensuite au problème
wtsang02

0

Le compilateur est un programme qui lit un programme écrit dans une langue (la langue source) et le traduit dans un autre programme équivalent dans une autre langue (la langue cible), principalement un langage machine.

Il existe différentes phases du compilateur à travers lesquelles votre code de langue source est analysé ligne par ligne. Il y a une table de symboles qui garde la trace de tous les mots-clés qui sont analysés dans le code de la langue source.

Phase 1: Lexical Analyzer - lit tous les caractères du programme source et forme la séparation logique des jetons (int, char, float, if-else, for, while etc.)

Phase 2: Syntax Analyzer - analysez la structure du flux de jetons. Analyse hiérarchique des expressions qui inclut le suffixe / préfixe, etc. (a = b + c * d)

Phase 3: Analyseur sémantique - Vérification de type des jetons (entier à réel, flottant, etc.) et de nombreuses choses comme la priorité des opérateurs, etc.

Phase 4: Générateur de code intermédiaire - a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

Phase 5: Optimisation du code - Diverses analyses (flux de contrôle, flux de données, transformations)
qui élémine: code de redondance, propagation des constantes, code mort partiel, sous-expression commune, code invariant de boucle

Phase 6: Génération de code - Génération de code cible (principalement un langage d'assemblage) mettant des valeurs dans les registres

Toutes ces phases ne sont rien d'autre que des programmes bien écrits et il pourrait y avoir N nombre de défauts.


-1

Bien sûr, les compilateurs ne sont que des programmes et leurs auteurs sont aussi des idiots :). Même les spécifications de langue peuvent avoir un bogue. Exemple: c # + foreach + lambda .

Ou en Python, bug dans l'interpréteur: la compilation de evil ast bloque l'interpréteur .

Eh bien, si vous voulez regarder les bogues dans le compilateur / l'interprète -> regardez php. Il existe un bogue célèbre avec débordement d'entier. Le premier correctif a commencé à partir de if (size > INT_MAX) return NULL;. Suite de l'histoire .


Les auteurs de compilateurs ne sont pas des idiots. Comme les compilateurs sont assez compliqués, la barrière pour entrer sur le terrain est également considérablement plus élevée. Nous pouvons donc nous attendre à ce que les personnes qui les écrivent ne commettent pas d'erreurs comme le font les gars moyens.
jszpilewski

Le foreach / lambda n'est pas un bug, cela revient à une décision de conception spécifique et consciente prise avant l'ajout de lambdas.
Andy

@Andy, comme je le sais, personne n'a su quels problèmes cette décision entraînera. Pourquoi pas bug?
Viktor Lova

@jszpilewski voyez-vous un sourire après ce texte?
Viktor Lova

1
Je vous suggère de relire l'OP, car sa question n'est pas de savoir si les spécifications peuvent avoir des bogues, mais si les COMPILATEURS peuvent avoir des bogues. Puisque le compilateur C # correspondait à la spécification, le compilateur n'avait pas de bogue. Je vous suggère également de relire votre propre citation de Wikipédia "Un bug logiciel est une erreur, une faille, une panne ou une erreur dans un programme informatique"
Andy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.