Ölü kodun derleyiciler tarafından algılanamayacağının kanıtı

Birisi derleyici olacak olan çok sayıda konuda bir kış kursu öğretmeyi planlıyorum. Şimdi, çeyrek boyunca vereceğim ödevleri düşünürken bu problemle karşılaştım, ama bunun yerine bir örnek olarak kullanabilmem için beni çok kızdırdı.

public class DeadCode {
  public static void main(String[] args) {
     return;
     System.out.println("This line won't print.");
  }
}

Yukarıdaki programda, print cümlesinin nedeniyle hiçbir zaman yürütülmeyeceği açıktır return. Derleyiciler bazen ölü kodla ilgili uyarılar veya hatalar verir. Örneğin, yukarıdaki kod Java ile derlenmeyecektir. Ancak javac derleyicisi her programdaki tüm ölü kod örneklerini algılamaz. Hiçbir derleyicinin bunu yapamayacağını nasıl kanıtlayabilirim?

Hepsi durma sorununun kararsızlığından geliyor. "Mükemmel" bir ölü kod fonksiyonuna, bazı Turing Machine M'ye ve bazı giriş dizgisine x sahip olduğumuzu ve buna benzer bir prosedürün olduğunu varsayalım:

Run M on input x;
print "Finished running input";

Eğer M sonsuza dek sürerse, o zaman asla ulaşamayacağımız için print deyimini siliyoruz. M sonsuza dek koşmazsa, print deyimini tutmamız gerekir. Böylece, bir ölü kod çıkarıcımız varsa, aynı zamanda Halting Problemini çözmemize de izin verir, böylece böyle bir ölü kod çıkarıcısının olamayacağını biliyoruz.

Bunu aşmanın yolu “muhafazakar yaklaşım” dır. Dolayısıyla yukarıdaki Turing Machine örneğimde, x üzerinde M çalıştırmanın bitebileceğini varsayabiliriz, bu nedenle güvenli oynar ve print deyimini kaldırmadık. Örneğinizde, hangi fonksiyonların durup durmadığının önemli olmadığı, bu baskı ifadesine ulaşmamızın mümkün olmadığını biliyoruz.

Genellikle, bu bir "kontrol-akış grafiği" yapılarak yapılır. Sonsuza kadar çalışsa veya yalnızca bir kez çalışsa ve her ikisini de ziyaret etmese bile, "bir süre döngüsünün sonu başlangıcı ve sonrasına bağlı" gibi basitleştirici varsayımlar yaparız. Benzer şekilde, if ifadesinin gerçekte hiç kullanılmamış olsa bile, tüm dallarına ulaşabileceğini varsayıyoruz. Bu tür sadeleştirmeler, verdiğiniz örnek gibi "açıkça ölü kodu" kaldırmamıza izin verirken karar vermemize izin verir.

Yorumlardaki bazı kafa karışıklıklarını netleştirmek için:

1. Nitpick: Sabit M için bu her zaman kararlaştırılabilir. M giriş olmalı

   Raphael’in dediği gibi benim örneğimde Turing Machine’i bir girdi olarak görüyoruz. Buradaki fikir, eğer mükemmel bir DCE algoritmasına sahip olsaydık, herhangi bir Turing Makinesi için verdiğim kod parçacığını kurabilirdik ve bir DCE'ye sahip olmak durma problemini çözebilirdi.

2. ikna olmadı. Şube yok dümdüz ileri bir uygulamada künt bir ifade olarak geri dönmeye karar vermek zor değil. (ve derleyicim bana bunun çözülebildiğini söylüyor)

   Njzk2 sorunu gündeme geldi: kesinlikle haklısın, bu durumda, iadeye ulaşılmasından sonra bir ifadenin olmadığını belirleyebilirsin. Bunun nedeni, kontrol-akış grafiği kısıtlamaları kullanarak erişilmezliğini tanımlayabileceğimiz kadar basit (yani, bir return ifadesinden hiçbir çıkış kenarı yok). Ancak kullanılmayan tüm kodları ortadan kaldıran mükemmel bir ölü kod giderici yoktur.

3. Giriş için bağımlı bir kanıt almıyorum. Kodun sınırlı olmasına izin verecek türde bir kullanıcı girişi varsa, derleyicinin aşağıdaki dalın ölmediğini varsayması doğru olur. Tüm bu artıların ne için olduğunu göremiyorum, her ikisi de açık (örneğin, sonsuz stdin) ve yanlış.

   Tomáš Zato için: bu gerçekten girdi bağımlı bir kanıt değil. Aksine, bir "forall" olarak yorumlayın. Aşağıdaki gibi çalışır: mükemmel bir DCE algoritmasına sahip olduğumuzu varsayalım. Bana keyfi bir Turing Makinesi M ve x girişi verirseniz, yukarıdaki kod parçasını oluşturarak ve print ifadesinin kaldırılıp kaldırılmadığını görerek, M'nin durup durmadığını belirlemek için DCE algoritmamı kullanabilirim. Forall ifadesini kanıtlamak için isteğe bağlı bir parametre bırakmak bu teknik matematik ve mantıkta yaygındır.

   TomášZato'nun kodun sonlu olduğu konusundaki noktasını tam olarak anlamadım. Elbette kod sonludur, ancak mükemmel bir DCE algoritması, bir infinte olan tüm koda uygulanmalıdır. Benzer şekilde, kodun kendisi sınırlı olsa da, olası girdi kümeleri, kodun olası çalışma süresi gibi sınırsızdır.

   Ölü olmayan son şubeyi göz önünde bulundurmakla ilgili olarak: bahsettiğim "muhafazakar yaklaşım" açısından güvenlidir, ancak OP'nin istediği gibi tüm ölü kod örneklerini tespit etmek yeterli değildir.

Bunun gibi bir kod düşünün:

while (true)
  print "Hello"
print "goodbye"

Açıkça print "goodbye"programın davranışını değiştirmeden kaldırabiliriz . Böylece, ölü koddur. Ancak (true), whiledurum yerine farklı bir işlev çağrısı varsa , o zaman kaldırabilir miyiz, kararsızlığa yol açıp açamayacağımızı bilmiyoruz.

Bunu kendi başıma yapmayacağımı unutmayın. Derleyiciler teorisinde iyi bilinen bir sonuçtur. Kaplan Kitabında tartışılıyor . ( Google kitaplarında nerede konuştuklarını görebilirsiniz .

Bu, jmite'nin sonlandırmama konusundaki potansiyel kafa karışıklığını gideren cevabındaki bir bükülmedir. Kendisini her zaman durduran, ölü kodlu bir program vereceğim, ancak algoritmasına sahip olup olmadığına (her zaman) karar veremiyoruz.

Ölü kod tanımlayıcısı için aşağıdaki girdi sınıflarını göz önünde bulundurun:

simulateMx(n) {
  simulate TM M on input x for n steps
  if M did halt
    return 0
  else
    return 1
}

Yana Mve xsabitlenir, simulateMsölü kodu vardır return 0ve ancak eğer Müzerinde durdurmak değil x.

Bu bize derhal durma probleminden ölü kod kontrolüne bir azalma sağlar: durma problemi örneği olarak TM verildiğinde , kodu ile yukarıda bir program hazırlayın - eğer sadece kendi başına durmazsa ölü kodu vardır kodu.$M$x$M$$M$

Bu nedenle, ölü kod kontrolü hesaplanamaz.

Bu bağlamda ispat tekniği olarak azaltma konusunda bilginiz yoksa referans materyalimizi öneriyorum .

Bu tür bir mülkü ayrıntılara dalmadan göstermenin basit bir yolu aşağıdaki lemayı kullanmaktır:

Lemma: Turing-tamamlanmış bir dil için herhangi bir C derleyicisi için undecidable_but_true(), hiçbir argüman almayan ve booleanı doğru döndüren bir işlev vardır, C'nin undecidable_but_true()doğru ya da yanlış olduğunu tahmin edemez .

İşlevin derleyiciye bağlı olduğunu unutmayın. Bir işlev verildiğinde undecidable_but_true1(), bir derleyiciye bu işlevin doğru mu yanlış mı döndüğü bilgisi ile her zaman artırılabilir; ama her zaman undecidable_but_true2()kapsanmayacak başka bir işlev vardır.

Kanıt: tarafından Rice'ın teoremi , mülkiyet “gerçek bu işlev döndürür” undecidable. Bu nedenle, herhangi bir statik analiz algoritması, tüm olası işlevler için bu özelliğe karar veremez.

Sonuç: Derleyici C verildiğinde, aşağıdaki program tespit edilemeyen bir ölü kod içeriyor:

if (!undecidable_but_true()) {
    do_stuff();
}

Java ile ilgili bir not: Java dili, derleyicilerin erişilemeyen kod içeren bazı programları reddetmesini zorunlu kılarken, bu kodun erişilebilir olan tüm noktalarda (örneğin geçersiz olmayan bir işlevdeki kontrol akışı bir returnifade ile bitmelidir ) kesin olarak zorunlu kılınmasını zorunlu kılar . Dil tam olarak erişilemeyen kod analizinin nasıl yapıldığını belirtir; o olmasaydı taşınabilir programlar yazmak imkansız olurdu. Formun bir program verilen

some_method () {
    <code whose continuation is unreachable>
    // is throw InternalError() needed here?
}

hangi durumlarda erişilemez kodun başka bir kodla takip edilmesi gerektiğini ve hangi durumlarda herhangi bir kodla takip edilmemesi gerektiğini belirtmek gerekir. Java 101'de, erişilemeyen ancak Java derleyicilerinin fark etmesine izin verecek şekilde olmayan kod içeren bir Java programı örneği şöyledir:

String day_of_week(int n) {
    switch (n % 7) {
    case 0: return "Sunday";
    case 1: case -6: return "Monday";
    …
    case 6: case -1: return "Saturday";
    }
    // return or throw is required here, even though this point is unreachable
}

jmite'nin cevabı, programın bir hesaplamadan çıkıp çıkmayacağına uygulanır - sadece sonsuz olduğu için, kodun ölülmesinden sonra çağrılmaz.

Bununla birlikte, başka bir yaklaşım daha var: Cevabı olan ancak bilinmeyen bir problem:

public void Demo()
{
  if (Chess.Evaluate(new Chessboard(), int.MaxValue) != 0)
    MessageBox.Show("Chess is unfair!");
  else
    MessageBox.Show("Chess is fair!");
}

public class chess
{
  public Int64 Evaluate(Chessboard Board, int SearchDepth)
  {
  ...
  }
}

Şüphesiz bu rutin gelmez ölü kod içerir - fonksiyon tek yolu ancak diğer değil yürütür bir cevap dönecektir. Yine de bulmakta iyi şanslar! Hafızam teorik bir bilgisayarın bunu evrenin ömrü boyunca çözebileceği bir şey değil.

Daha ayrıntılı olarak:

Evaluate()Her iki taraf da (maksimum arama derinliği) kusursuzca oynarsanız yan bir satranç oyunları kazanır fonksiyon değerlerini hesaplar.

Satranç değerlendiricileri normalde mümkün olan her harekete belirli bir derinlik taşıyarak ileriye bakarlar ve sonra tahtayı bu noktada puanlamaya çalışırlar (bazen bazı dalları bir borsadan veya benzerinden yarıya baktıkça uzatarak çok eğrilmiş bir algı yaratabilir.) Gerçek maksimum derinlikten itibaren 17695 yarım hareket eder arama kapsamlı, olası her satranç oyununu geçecek. Tüm oyunların sona ermesinden dolayı, her bir tahtanın ne kadar iyi bir pozisyon olduğuna karar vermeye çalışmanın bir sorunu yoktur (ve böylece tahta değerlendirme mantığına bakmak için hiçbir sebep yoktur - asla çağrılmaz), sonuç ya bir kazanç, bir kayıp veya bir çizim. Sonuç beraberlik ise oyun adil, sonuç beraberlik değilse bu adil olmayan bir oyundur. Onu biraz genişletmek için:

public Int64 Evaluate(Chessboard Board, int SearchDepth)
{
  foreach (ChessMove Move in Board.GetPossibleMoves())
    {
      Chessboard NewBoard = Board.MakeMove(Move);
      if (NewBoard.Checkmate()) return int.MaxValue;
      if (NewBoard.Draw()) return 0;
      if (SearchDepth == 0) return NewBoard.Score();
      return -Evaluate(NewBoard, SearchDepth - 1);
    }
}

Ayrıca, derleyicinin Chessboard.Score () kodunun ölü kod olduğunu fark etmesi neredeyse imkansız olacak. Satranç kurallarının bilgisi, insanların bunu çözmemize izin verir, ancak bunu çözebilmek için MakeMove'un parça sayısını asla artıramayacağını ve Chessboard.Draw () 'ın parça sayısı çok uzun süre statik kalırsa doğru döneceğini bilmek zorundasınız. .

Arama derinliğinin tüm hareketlerin değil, yarım hareket halinde olduğunu unutmayın. Bu, bu tür AI yordamı için normaldir, çünkü O (x ^ n) yordamıdır - bir tane daha arama katmanı eklemek, ne kadar süreceği üzerinde büyük bir etkiye sahiptir.

Ben bir hesaplama dersinde, derleme zamanı ile çalışma zamanı arasındaki farkı anlama bağlamında ölü kod kavramının ilginç olduğunu düşünüyorum!

Bir derleyici, hiçbir derleme zamanı senaryosunda hiçbir zaman geçilemeyecek bir kodunuzun olup olmadığını belirleyebilir, ancak çalışma zamanı için bunu yapamaz. Loop-break testi için kullanıcı girişi olan basit bir while-loop bunu göstermektedir.

Bir derleyici çalışma zamanı ölü kodunu gerçekten belirleyebiliyorsa (örneğin, Turing tamamlandı), o zaman işin zaten bitmiş olması nedeniyle kodun çalıştırılması gerekmediği bir argüman var!

Başka bir şey olmazsa, derleme zamanı ölü kod kontrollerini geçen kodun varlığı girdiler ve genel kodlama hijyeninde (gerçek projelerin gerçek dünyasında) pragmatik sınır kontrolünün gerekliliğini göstermektedir.