Se il lavoro di un compilatore sta essenzialmente traducendo il codice sorgente in codice a livello macchina, può esserci qualche problema tecnico in un compilatore, cioè una "traduzione" errata?
Lo stesso vale per un interprete: può non riuscire a produrre il contenuto richiesto a volte?
Non ho mai sentito alcun bug nei compilatori / interpreti, ma esistono?
Tendi a trovarli di più in lingue che sono attivamente sviluppate rispetto a quelle che sono 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 vari "stadi" di stabilità. Una build notturna è molto meno probabile che sia stabile rispetto a un release candidate , che a sua volta ha meno probabilità di essere stabile rispetto a una versione completamente rilasciata e utilizzata attivamente.
Fortunatamente la maggior parte di questi linguaggi (in particolare quelli che sono open source) avrà un sistema di tracciamento dei bug pubblico a cui è possibile inviare rapporti.
Nella mia esperienza personale, mi sono imbattuto in errore 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 di linguaggio sono stati abbastanza intelligenti da includere una nota utile nell'output del log degli errori, suggerendo che quello che avrei incontrato era in realtà un errore del compilatore e ho detto dove inviare il report.
In parole semplici:
Tutti i programmi possono avere bug.
I compilatori sono programmi.
Ergo, i compilatori possono avere bug.
Ci possono essere errori anche nell'hardware; un esempio famoso è l'errore Pentium FDIV . Senza dubbio c'è la possibilità che i compilatori contengano errori.
Anche i compilatori e gli interpreti sono software, quindi non sono esenti da nessuno dei problemi di altri software.
Questo è un esempio di un compilatore recente come MSVC 11 (2012) e ecco un articolo su come testano il back-end .
Ovviamente, perché i compilatori sono software.
Nel 2005, ho avuto un errore di codice in un software molto critico che avevo scritto per una grande azienda. Dal momento che costava letteralmente alla società milioni di dollari per rettificare, ovviamente hanno lanciato una grande inchiesta.
Per fortuna (dal mio punto di vista), il problema si è rivelato essere un problema con il compilatore in Delphi. Nel blocco try finally, il valore di ritorno di una funzione è stato distrutto e ha restituito risultati assolutamente casuali al chiamante. Questo è stato documentato e riconosciuto da Borland.
.NET era noto per avere letteralmente centinaia di perdite di memoria diverse, in particolare nelle sue prime implementazioni.
Direi che non esiste software bugless. 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 controversi, quindi il loro track record è stato, nel complesso, abbastanza buono.
Sì.
Inoltre, non solo con i compilatori, ma anche con interpreti / debugger e qualsiasi strumento software di terze parti.
Al momento utilizziamo alcuni software di terze parti e abbiamo riscontrato alcuni problemi. A volte ci ringraziano, per aver trovato e segnalato un bug. :)
Alcuni di loro hanno anche alcune 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 ha bug per far funzionare correttamente l'applicazione?
Il compilatore è un programma che legge un programma scritto in una lingua (la lingua di partenza) e lo traduce in un altro programma equivalente in un'altra lingua (la lingua di destinazione), per lo più linguaggio macchina.
Ci sono diverse fasi del compilatore attraverso le quali il codice della tua lingua sorgente viene scansionato riga per riga. C'è una tabella dei simboli che tiene traccia di tutte le parole chiave che sono state scansionate nel codice della lingua sorgente.
Fase 1: Lexical Analyzer - legge tutto il carattere nel programma sorgente e forma il separazione logica dei token (int, char, float, if-else, for, while ecc.)
Fase 2: Analizzatore di sintassi: analizza la struttura del flusso di token. Hierarchical analisi di espressioni che include suffisso / prefisso ecc. (A = b + c * d)
Fase 3: Semantic Analyzer - Digitare il controllo dei token (da intero a reale, float ecc.) e molte cose come la precedenza degli operatori ecc.
Fase 4: generatore di codice intermedio - a = b + c * d-e (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)
Fase 5: Ottimizzazione del codice - Varie analisi (flusso di controllo, flusso di dati, trasformazioni)
che elemina: codice ridondante, propagazione delle costanti, codice morto parziale,
sottoespressione comune, codice invariante di loop
Fase 6: Generazione del codice - Generazione del codice di destinazione (Mostly Assembly Language) 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 le specifiche del linguaggio possono avere un bug. Esempio: c # + foreach + lambda .
O in Python, bug nell'interprete: Compilazione dell'interprete malvagio ast crash .
Bene, se vuoi vedere i bug nel compilatore / nell'interpeter - > guarda php. C'è un famoso bug con overflow intero. La prima correzione è iniziata da if (size > INT_MAX) return NULL; . Continuazione della storia .
Leggi altre domande sui tag bug compiler interpreters