Os compiladores e intérpretes podem ter bugs, e o que podemos fazer (como usuários) para lidar com eles? [fechadas]

Se o trabalho de um compilador estiver traduzindo essencialmente o código fonte para o código no nível da máquina, pode haver alguma falha no compilador, ou seja, uma "tradução" defeituosa?

O mesmo vale para um intérprete: ele pode falhar na saída do conteúdo necessário algumas vezes?

Eu não ouvi nenhum bug em compiladores / intérpretes, mas eles existem?

sim

Você tende a encontrá-los mais em idiomas que estão sendo desenvolvidos ativamente do que naqueles que são relativamente maduros (e, portanto, não vêem muitas mudanças frequentemente). É provavelmente por isso que a maioria dos idiomas é lançada em vários 'estágios' de estabilidade. É muito menos provável que uma construção noturna seja estável que um candidato a lançamento , o que é menos provável que seja estável que uma versão totalmente liberada e usada ativamente.

Felizmente, a maioria desses idiomas (especialmente os de código aberto) terá um sistema público de rastreamento de erros ao qual você pode enviar relatórios.

Na minha própria experiência, encontrei um bug bastante obscuro, mas grave, no Scala no Windows . Enviei minhas descobertas ao rastreador de erros e o problema foi corrigido rapidamente. Nesse caso, os desenvolvedores de idiomas foram espertos o suficiente para incluir uma observação útil na saída do log de erros, sugerindo que o que eu encontrei era de fato um erro do compilador e disseram para onde enviar o relatório.

Nas palavras dos leigos:

Todos os programas podem ter erros.

Compiladores são programas.

Portanto, os compiladores podem ter bugs.

Pode haver erros mesmo no hardware; Um exemplo famoso é o bug do Pentium FDIV . Sem dúvida, existe a possibilidade de que os compiladores contenham erros.

Compiladores e intérpretes também são software e, portanto, não estão livres de nenhum dos problemas de outros softwares.

Este é um exemplo de um compilador tão recente quanto o MSVC 11 (2012) e aqui está um artigo sobre como eles testam o back-end .

Obviamente, porque compiladores são software.

Em 2005, um código falhou em um software altamente crítico que eu havia escrito para uma grande empresa. Como a empresa literalmente custou milhões de dólares para retificá-la, eles naturalmente iniciaram uma investigação importante.

Felizmente (da minha perspectiva), o problema acabou sendo um problema de compilação no Delphi. No bloco try finalmente, o valor de retorno de uma função foi destruído e resultou em resultados absolutamente aleatórios de volta para o chamador. Isso foi documentado e reconhecido pela Borland.

O .NET era conhecido por ter literalmente centenas de diferentes vazamentos de memória, principalmente em suas implementações iniciais.

Eu diria que não existe software sem erros. Compiladores não são excepção. Eles são, no entanto, testados mais detalhadamente do que a maioria dos softwares de negócios e são consumidos por pessoas inteligentes, críticas e contenciosas; portanto, seu histórico, na verdade, tem sido bastante bom.

Não apenas erros, mas também malware deliberado.

O trojan "login" implementado por Brian Kernighan no compilador Unix C original é o mais conhecido deles; o artigo http://cm.bell-labs.com/who/ken/trust.html possui alguns antecedentes sobre isso.

Sim, claro, como qualquer compilador de software tem bugs, por exemplo, a lista de bugs do gcc está aqui

Sim.

Além disso, não apenas com compiladores, mas também com intérpretes / depuradores e qualquer ferramenta de software de terceiros.

No momento, estamos usando algum software de terceiros e estamos enfrentando alguns dos problemas. Às vezes, eles nos agradecem por encontrar e relatar um bug. :)

Alguns deles também têm alguns vazamentos de memória, o que leva ao travamento. A questão importante aqui pode ser: como determinar se a ferramenta de terceiros ou o compilador possui bugs para que seu aplicativo funcione corretamente?

Compilador é um programa que lê um programa escrito em um idioma (o idioma de origem) e o converte em outro programa equivalente em outro idioma (o idioma de destino), principalmente o idioma de máquina.

Existem diferentes fases do compilador através das quais o código do idioma de origem é verificado linha por linha. Existe uma tabela de símbolos que mantém o controle de todas as palavras-chave pesquisadas no código do idioma de origem.

Fase 1: Lexical Analyzer - lê todo o caractere no programa de origem e forma a separação lógica de tokens (int, char, float, if-else, por, while etc.)

Fase 2: Analisador de Sintaxe - analise a estrutura do fluxo de tokens. Análise hierárquica de expressões que inclui postfix / prefixo etc. (a = b + c * d)

Fase 3: Analisador Semântico - Verificação de tipo de tokens (inteiro para real, flutuante etc.) e muitas coisas como precedência do operador etc.

Fase 4: Gerador de código intermediário - a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

Fase 5: Otimização de Código - Análise Diversa (fluxo de controle, fluxo de dados, transformações)
que elimina: código de redundância, propagação de constantes, código morto parcial, subexpressão comum, código invariante de loop

Fase 6: Geração de código - geração de código de destino (principalmente Assembly Language) colocando valores nos registros

Todas essas fases nada mais são do que programas bem escritos e pode haver um número N de falhas nisso ..

Obviamente, compiladores são apenas programas e seus autores também são idiotas :). Até a especificação da linguagem pode ter um erro. Exemplo: c # + foreach + lambda .

Ou no Python, erro no intérprete: Compilar o mal ast trava o intérprete .

Bem, se você quiser procurar por bugs no compilador / interpeter -> veja php. Existe um bug famoso com excesso de número inteiro. Primeira correção iniciada em if (size > INT_MAX) return NULL;. Continuação da história .