I compilatori e gli interpreti possono avere bug e cosa possiamo fare (come utenti) per gestirli? [chiuso]

Se il lavoro di un compilatore sta essenzialmente traducendo il codice sorgente in codice a livello di macchina, può esserci qualche problema tecnico in un compilatore, cioè una "traduzione" difettosa?

Lo stesso vale per un interprete: a volte può non riuscire a produrre il contenuto richiesto?

Non ho sentito parlare di bug nei compilatori / interpreti, ma esistono?

sì

Tendi a trovarli più nelle lingue che sono attivamente sviluppate che in quelle relativamente mature (e quindi non vedono molti cambiamenti su base frequente). Questo è probabilmente il motivo per cui la maggior parte delle lingue viene rilasciata in varie 'fasi' di stabilità. Una build notturna ha molte meno probabilità di essere stabile rispetto a un candidato al rilascio , che a sua volta ha meno probabilità di essere stabile rispetto a una versione completamente rilasciata e utilizzata attivamente.

Fortunatamente la maggior parte di queste lingue (specialmente quelle che sono open source) avrà un sistema di tracciamento dei bug pubblico a cui è possibile inviare segnalazioni.

Nella mia esperienza, ho riscontrato un bug piuttosto oscuro ma grave in Scala su Windows . Ho inviato i miei risultati al bug tracker e il problema è stato risolto abbastanza rapidamente. In quel caso, gli sviluppatori del linguaggio erano abbastanza intelligenti da includere una nota utile nell'output del registro degli errori, suggerendo che ciò che avrei incontrato era in realtà un errore del compilatore e dicevano dove inviare il rapporto.

Nelle parole di laici:

Tutti i programmi possono contenere bug.

I compilatori sono programmi.

Ergo, i compilatori possono avere dei bug.

Ci possono essere bug anche nell'hardware; un famoso esempio è il bug Pentium FDIV . Senza dubbio c'è la possibilità che i compilatori contengano bug.

Anche i compilatori e gli interpreti sono software e quindi non sono esenti da problemi di altri software.

Questo è un esempio di un compilatore recente come MSVC 11 (2012) , ed ecco un articolo su come testano il backend .

Certo, perché i compilatori sono software.

Nel 2005, ho avuto un pezzo di codice fallito in un pezzo di software altamente critico che avevo scritto per una grande azienda. Poiché costare alla società letteralmente milioni di dollari per rettificare, hanno ovviamente avviato un'indagine approfondita.

Per fortuna (dal mio punto di vista), il problema si è rivelato essere un problema del compilatore in Delphi. Nel blocco try finally, il valore restituito di una funzione è stato distrutto e ha restituito al chiamante risultati assolutamente casuali. Questo è stato documentato e riconosciuto da Borland.

.NET era noto per avere letteralmente centinaia di diverse perdite di memoria, in particolare nelle sue prime implementazioni.

Direi che non esiste software senza errori. I compilatori non fanno eccezione. Tuttavia, sono testati in modo più approfondito rispetto alla maggior parte dei software aziendali e sono consumati da persone intelligenti, critiche e controverse, quindi il loro track record è stato, nel complesso, abbastanza buono.

Non solo bug, ma anche malware deliberato.

Il trojan "login" implementato da Brian Kernighan nel compilatore originale di Unix C è il più noto di questi; l'articolo http://cm.bell-labs.com/who/ken/trust.html contiene alcune informazioni al riguardo.

Sì, certo come tutti i compilatori di software hanno dei bug, ad esempio l'elenco dei bug di gcc è qui

Sì.

Inoltre, non solo con compilatori, ma anche con interpreti / debugger e qualsiasi strumento software di terze parti.

Attualmente stiamo utilizzando alcuni software di terze parti e abbiamo riscontrato alcuni dei problemi. A volte ci ringraziano per aver trovato e segnalato un bug. :)

Alcuni hanno anche delle perdite di memoria, il che porta a crash. La domanda importante qui potrebbe essere: come determinare se lo strumento di terze parti o il compilatore presenta bug per il corretto funzionamento dell'applicazione?

Il compilatore è un programma che legge un programma scritto in una lingua (la lingua di origine) e lo traduce in un altro programma equivalente in un'altra lingua (la lingua di destinazione), principalmente in linguaggio macchina.

Esistono diverse fasi del compilatore attraverso cui il codice della lingua sorgente viene scansionato riga per riga. C'è una tabella dei simboli che tiene traccia di tutte le parole chiave che vengono scansionate nel codice della lingua sorgente.

Fase 1: Lexical Analyzer: legge tutto il carattere nel programma sorgente e forma la separazione logica dei token (int, char, float, if-else, for, while, ecc.)

Fase 2: Syntax Analyzer: analizza la struttura del flusso di token. Analisi gerarchica di espressioni che include postfisso / prefisso ecc. (A = b + c * d)

Fase 3: Analizzatore semantico - Verifica del tipo di token (intero su reale, float ecc.) E molte cose come la precedenza dell'operatore ecc.

Fase 4: generatore di codice intermedio - a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

Fase 5: Ottimizzazione del codice - Varie analisi (flusso di controllo, flusso di dati, trasformazioni)
che emana: codice di ridondanza, propagazione delle costanti, codice morto parziale, sottoespressione comune, codice invariante di loop

Fase 6: generazione di codice - Generazione di codice target (principalmente linguaggio assembly) che inserisce valori nei registri

Tutte queste fasi non sono altro che programmi ben scritti e potrebbe esserci un numero N di difetti in questo ..

Naturalmente, i compilatori sono solo dei programmi e anche i loro autori sono idioti :). Anche la specifica della lingua può avere un bug. Esempio: c # + foreach + lambda .

O in Python, bug nell'interprete: compilazione malefica per l'interprete in crash .

Bene, se vuoi esaminare i bug nel compilatore / interpeter -> guarda php. Esiste un bug famoso con overflow di numeri interi. La prima correzione è iniziata da if (size > INT_MAX) return NULL;. Continuazione della storia .