Jeśli ktoś ma kod źródłowy dla kompilatora / systemu kompilacji, którego dane wyjściowe nie powinny zależeć od niczego poza zawartością dostarczonych plików źródłowych, i jeśli ktoś ma kilka innych kompilatorów i wie, że nie wszystkie zawierają ten sam hack kompilatora, można upewnij się, że otrzymujesz plik wykonywalny, który nie zależy od niczego innego niż kod źródłowy.
Załóżmy, że ktoś ma kod źródłowy pakietu kompilatora / linkera (powiedzmy Groucho Suite) napisany w taki sposób, że jego wynik nie będzie zależał od żadnych nieokreślonych zachowań, ani od niczego innego niż zawartość wejściowych plików źródłowych, a jeden kompiluje / łączy ten kod w różnych niezależnie produkowanych kompilatorach / pakietach łączących (np. Harpo Suite, Chico Suite i Zeppo Suite), uzyskując dla każdego inny zestaw ekwiwalentów (nazywaj je G-Harpo, G-Chico i G-Zeppo). Nie byłoby niespodzianką, że te pliki wykonywalne zawierają różne sekwencje instrukcji, ale powinny być funkcjonalnie identyczne. Jednak udowodnienie, że są one funkcjonalnie identyczne we wszystkich przypadkach, prawdopodobnie stanowiłoby trudny problem.
Na szczęście taki dowód nie będzie konieczny, jeśli użyje się wynikowych plików wykonywalnych tylko w jednym celu: ponownej kompilacji pakietu Groucho. Jeśli jeden kompiluje pakiet Groucho za pomocą G-Harpo (uzyskując GG-Harpo), G-Chico (GG-Chico) i G-Zeppo (GG-Zeppo), wówczas wszystkie trzy wynikowe pliki, GG-Harpo, GG-Chico i GG-Zeppo, wszystkie bajty po bajcie powinny być identyczne. Jeśli pliki się zgadzają, oznaczałoby to, że każdy „wirus kompilatora”, który istnieje w jednym z nich, musi istnieć identycznie we wszystkich (ponieważ wszystkie trzy pliki są identyczne bajt po bajcie, nie ma możliwości, aby ich zachowanie mogło się różnić droga).
W zależności od wieku i pochodzenia innych kompilatorów może być możliwe zapewnienie, że taki wirus nie będzie w nich istniał. Na przykład, jeśli ktoś użyje antycznego Macintosha, aby nakarmić kompilator napisany od zera w 2007 r. Za pomocą wersji MPW napisanej w latach 80., kompilatory z lat 80. nie będą wiedziały, gdzie wstawić wirusa w kompilatorze z 2007 r. Możliwe, że dziś kompilator może wykonać wystarczająco wymyślną analizę kodu, aby to rozgryźć, ale poziom obliczeń wymagany do takiej analizy znacznie przekroczyłby poziom obliczeń wymagany do zwykłego skompilowania kodu i nie mógłby nie zostać niezauważony na rynku, gdzie szybkość kompilacji była głównym punktem sprzedaży.
Zakładam, że jeśli ktoś pracuje z narzędziami do kompilacji, w których bajty w pliku wykonywalnym, który ma zostać wygenerowany, nie powinno w żaden sposób zależeć od niczego poza zawartością przesłanych plików źródłowych, możliwe jest uzyskanie względnie dobrej odporności na Thompson wirus typu. Niestety z jakiegoś powodu niedeterminizm w kompilacji wydaje się być uważany za normalny w niektórych środowiskach. Rozumiem, że w systemie wieloprocesorowym kompilator może działać szybciej, jeśli pewne aspekty generowania kodu mogą się różnić w zależności od tego, który z dwóch wątków kończy pracę jako pierwszy.
Z drugiej strony nie jestem pewien, czy widzę jakiś powód, dla którego kompilatory / konsolidatory nie powinny zapewniać trybu „kanonicznego wyjścia”, w którym dane wyjściowe zależą tylko od plików źródłowych i „daty kompilacji”, która może zostać zastąpiona przez użytkownika . Nawet jeśli kompilacja kodu w takim trybie zajęła dwa razy więcej czasu niż normalna kompilacja, sugerowałbym, że istotną wartością byłoby odtworzenie „kompilacji wydania”, bajt po bajcie, całkowicie z materiałów źródłowych, nawet jeśli oznaczałoby to, że kompilacje wersji zajęłyby dłużej niż „normalne kompilacje”.