Czy kompilatory i tłumacze mogą mieć błędy i co my (jako użytkownicy) możemy sobie z nimi poradzić? [Zamknięte]

28

Jeśli praca kompilatora polega głównie na tłumaczeniu kodu źródłowego na kod maszynowy, czy w kompilatorze może być jakaś usterka, np. Błędne „tłumaczenie”?

To samo dotyczy tłumacza: czy czasami nie może wygenerować wymaganej treści?

Nie słyszałem o żadnych błędach w kompilatorach / tłumaczach, ale czy one istnieją?

Król czarownic
źródło
6
w fazie rozwoju z pewnością będą istnieć, wystarczy spojrzeć na bugtrackera na dowolnym kompilatorze open source
maniak ratchet
7
Nie słyszałem o żadnych błędach w kompilatorach / tłumaczach, ale czy one istnieją? Znalazłem listę mailingową błędów w kompilatorze gcc: gcc.gnu.org/ml/gcc-bugs
FrustratedWithFormsDesigner
47
To nie jest dobre pytanie, po prostu zadaje coś zdrowego rozsądku.
12
Żadna z komentarzy lub odpowiedzi nie dotyczy do tej pory prawdopodobieństwa wystąpienia błędu kompilatora. Najpierw należy wykluczyć błędy we własnym kodzie.
Dan Pichelman,
6
Krótka odpowiedź: zdecydowanie. Podczas gdy IDE i kompilatory są zwykle wykonywane w ciągu jednego cala ich życia, zanim jeszcze zobaczą świat zewnętrzny, zawsze jest jakiś przypadek, w którym znajdzie się zbyt sprytny programista.
KeithS,

Odpowiedzi:

51

tak

Masz tendencję do znajdowania ich bardziej w językach, które są aktywnie rozwijane, niż w tych, które są stosunkowo dojrzałe (i dlatego nie widzą często dużych zmian). Prawdopodobnie dlatego większość języków jest wydawana na różnych „etapach” stabilności. Kompilacja nocna jest znacznie mniej stabilna niż kandydat do wydania , który sam jest mniej prawdopodobny niż wersja w pełni wydana i aktywnie używana.

Na szczęście większość tych języków (zwłaszcza tych o otwartym kodzie źródłowym) będzie mieć publiczny system śledzenia błędów , do którego można przesyłać raporty.

Z własnego doświadczenia natrafiłem na dość niejasny, ale poważny błąd w Scali na Windowsie . Przesłałem swoje ustalenia do narzędzia do śledzenia błędów, a problem został naprawiony dość szybko. W takim przypadku twórcy języków byli na tyle sprytni, że umieścili pomocną notatkę w danych wyjściowych dziennika błędów, sugerując, że to, na co wpadłem, to w rzeczywistości błąd kompilatora, i powiedzieli, gdzie przesłać raport.

KChaloux
źródło
Mam nadzieję, że nie masz nic przeciwko; Dodałem nowy akapit (w oczekiwaniu na zatwierdzenie), który moim zdaniem może być istotny. Kompilator może nie tylko zawierać błędy, ale może również zawierać złośliwy kod.
Andy,
@Andy wygląda na to, że jeden z moderatorów odrzucił go jako coś, co powinno być komentarzem lub osobną odpowiedzią.
KChaloux
Nie tylko „tak”, ale „do diabła tak!” :-)
Hellion,
C jest zarówno dojrzały, jak i aktywnie rozwijany. Podobnie jak C ++. Podobnie jak Java. itp ..
djechlin
100

Słowami laika:

Wszystkie programy mogą zawierać błędy.

Kompilatory to programy.

Ergo, kompilatory mogą mieć błędy.

Tulains Córdova
źródło
55
Bardziej niepokojące: Debugery to programy. Dlatego debuggery mają błędy.
Daniel Gratzer
19
@ jozefg: Więc jak debugujesz debugger? Kto ogląda obserwatorów?
FrustratedWithFormsDesigner
16
@FrustratedWithFormsDesigner Obserwatorzy obserwujący, duh.
Jimmy Hoffa
9
@JoelFan Ponieważ napisałem „może mieć”, wyjątek ten jest objęty. Jeśli powiesz „masz”, musisz określić, że masz na myśli tylko programy niebanalne. Mówiąc „może mieć”, nie musisz.
Tulains Córdova
8
Programy „Hello world” mogą zawierać błędy, jeśli są zgodne z błędnym kompilatorem.
wtsang02
22

Mogą występować błędy nawet w sprzęcie; znanym przykładem jest błąd Pentium FDIV . Bez wątpienia istnieje możliwość, że kompilatory zawierają błędy.

m3th0dman
źródło
2
+1 To doprowadziło mnie do historii drapieżnej małpy .
luser droog
4

Oczywiście, ponieważ kompilatory to oprogramowanie.

W 2005 r. Wystąpił błąd kodu w wysoce krytycznym oprogramowaniu napisanym dla dużej firmy. Ponieważ rektyfikacja kosztowała firmę dosłownie miliony dolarów, oczywiście wszczęli oni wielkie śledztwo.

Na szczęście (z mojej perspektywy) problem okazał się problemem kompilatora w Delphi. W bloku try w końcu wartość zwracana przez funkcję została zniszczona i skutkowała absolutnie losowymi wynikami z powrotem do obiektu wywołującego. Zostało to udokumentowane i potwierdzone przez Borlanda.

.NET był znany z dosłownie setek różnych wycieków pamięci, szczególnie we wczesnych implementacjach.

Twierdziłbym, że nie ma czegoś takiego jak oprogramowanie bezbłędne. Kompilatory nie są wyjątkiem. Są one jednak testowane dokładniej niż większość oprogramowania biznesowego i są spożywane przez inteligentnych, krytycznych, kontrowersyjnych ludzi, więc ich historia była w zasadzie całkiem niezła.

Lakoniczny
źródło
Istnieje oprogramowanie „formalnie zweryfikowane”. Udowodniono matematycznie, że działa. Czasami nawet formalnie zweryfikowany kod zawiera błędy. Szybka implementacja IIRC Java w Javie została formalnie zweryfikowana, ale nie uwzględniało to przepełnienia.
David Plumpton,
1
Jakie było oprogramowanie?
Dalej
2

Nie tylko błędy, ale także celowe złośliwe oprogramowanie.

Najbardziej znany z nich jest trojan „login” zaimplementowany przez Briana Kernighana w oryginalnym kompilatorze Unix C. artykuł http://cm.bell-labs.com/who/ken/trust.html ma na ten temat pewne podstawy.

Juha Laiho
źródło
1
Czy jasne jest, że tak naprawdę zostało wdrożone?
Keith Thompson,
To dość interesujący temat, ale wcale nie związany z tym pytaniem.
@delnan Nie zgadzam się; sednem pytania wydaje się być „jak bardzo mogę zaufać mojemu kompilatorowi?”
Andy,
1

Tak, oczywiście, jak każdy kompilator oprogramowania ma błędy, na przykład lista błędów gcc jest tutaj

JohnB
źródło
0

Tak.

Ponadto nie tylko z kompilatorami, ale także z interpreterami / debuggerami i dowolnymi narzędziami programowymi innych firm.

Obecnie używamy oprogramowania innych firm i mieliśmy problem. Czasami dziękują nam za znalezienie i zgłoszenie błędu. :)

Niektóre z nich mają także wycieki pamięci, co prowadzi do awarii. Ważnym pytaniem może być tutaj: jak ustalić, czy narzędzie innej firmy lub kompilator zawiera błędy, aby aplikacja działała poprawnie?

JNL
źródło
Wasze ważne pytanie doprowadzi następnie do problemu zatrzymania
wtsang02,
0

Kompilator to program, który czyta program napisany w jednym języku (języku źródłowym) i tłumaczy go na inny równoważny program w innym języku (języku docelowym), głównie języku maszynowym.

Istnieją różne fazy kompilatora, przez które kod języka źródłowego jest skanowany wiersz po wierszu. Istnieje tablica symboli, która śledzi wszystkie słowa kluczowe skanowane w kodzie języka źródłowego.

Faza 1: Analizator leksykalny - odczytuje wszystkie znaki w programie źródłowym i tworzy logiczną separację tokenów (int, char, float, if-else, for, while itp.)

Faza 2: Analizator składni - przeanalizuj strukturę strumienia tokenów. Hierarchiczna analiza wyrażeń, która zawiera postfiks / prefiks itp. (A = b + c * d)

Faza 3: Analizator semantyczny - Sprawdzanie typu tokenów (od liczb całkowitych do rzeczywistych, liczb zmiennoprzecinkowych itp.) I wiele innych rzeczy, takich jak pierwszeństwo operatorów itp

Faza 4: Generator kodów pośrednich - a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

Faza 5: Optymalizacja kodu - różne analizy (przepływ sterowania, przepływ danych, transformacje),
które eliminują: kod nadmiarowy, propagowanie stałych, częściowy martwy kod, wspólne podwyrażenie, niezmienny kod pętli

Faza 6: Generowanie kodu - Generowanie kodu docelowego (głównie języka asemblera) wprowadzającego wartości do rejestrów

Wszystkie te fazy to nic innego, jak dobrze napisane programy, w których może być N wad.

Abhishek Kulkarni
źródło
-1

Oczywiście, kompilatory to tylko programy, a ich autorzy też są idiotami :). Nawet specyfikacja języka może zawierać błąd. Przykład: c # + foreach + lambda .

Lub w Pythonie, błąd w tłumaczu : Kompilacja zła ast powoduje awarię tłumacza .

Cóż, jeśli chcesz spojrzeć na błędy w kompilatorze / interpeter -> spójrz na php. Istnieje znany błąd związany z przepełnieniem liczb całkowitych. Pierwsza poprawka rozpoczęła się od if (size > INT_MAX) return NULL;. Kontynuacja historii .

Viktor Lova
źródło
Autorzy kompilatorów nie są idiotami. Ponieważ kompilatory są dość skomplikowane, bariera wejścia na pole jest również znacznie wyższa. Możemy więc oczekiwać, że ludzie, którzy je piszą, nie popełniają błędów tak jak zwykli ludzie.
jszpilewski
Foreach / lambda nie jest błędem, sprowadza się do konkretnej decyzji sumienia podjętej przed dodaniem lambda.
Andy,
@Andy, jak wiem, nikt nie wiedział, jakie problemy spowoduje ta decyzja. Dlaczego nie błąd?
Viktor Lova,
@jszpilewski widzisz uśmiech po tym tekście?
Viktor Lova
1
Sugeruję ponowne przeczytanie OP, ponieważ jego pytanie nie dotyczy tego, czy specyfikacje mogą zawierać błędy, ale tego, czy KOMPILERY mogą mieć błędy. Ponieważ kompilator C # pasował do specyfikacji, kompilator nie miał błędu. Sugeruję również ponowne przeczytanie własnego cytatu z Wikipedii „Błąd oprogramowania to błąd, usterka, awaria lub usterka w programie komputerowym”
Andy