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

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ą?

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.

Słowami laika:

Wszystkie programy mogą zawierać błędy.

Kompilatory to programy.

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

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.

Kompilatory i interpretatory są również oprogramowaniem, a zatem nie są wolne od problemów innych programów.

To jest przykład kompilatora najnowszego jak MSVC 11 (2012) , a oto artykuł o tym, jak testują backend .

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.

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.

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

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?

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.

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 .