Neden ölü kod tespiti bir derleyici tarafından tam olarak çözülemiyor?

C veya Java'da kullandığım derleyicilerde ölü kod önleme var (bir satırın yürütülmediği zaman uyarı). Profesörüm bu sorunun derleyiciler tarafından asla tam olarak çözülemeyeceğini söylüyor. Bunun neden olduğunu merak ediyordum. Teori temelli bir sınıf olduğu için derleyicilerin gerçek kodlamasına pek aşina değilim. Ama neyi kontrol ettiklerini (olası giriş dizeleri ile kabul edilebilir girişler vs) ve bunun neden yetersiz olduğunu merak ediyordum.

Ölü kod sorunu Durma sorunuyla ilgilidir .

Alan Turing, bir program verilecek genel bir algoritma yazmanın ve o programın tüm girdiler için durup durmadığına karar vermenin imkansız olduğunu kanıtladı. Belirli program türleri için böyle bir algoritma yazabilirsiniz, ancak tüm programlar için yazamazsınız.

Bunun ölü kodla ilişkisi nedir?

Durdurma problemi ölü kod bulma problemine indirgenebilir . Yani ölü kodunu tespit edebilen bir algoritma bulursan olduğu herhangi bir program, o zaman ister teste o algoritmayı kullanarak herhangi bir program durduracak. Bunun imkansız olduğu kanıtlandığı için, ölü kod için bir algoritma yazmanın da imkansız olduğu anlaşılmaktadır.

Ölü kod için bir algoritmayı Durdurma sorunu için bir algoritmaya nasıl aktarırsınız?

Basit: Durdurmak için kontrol etmek istediğiniz programın sonuna bir satır kod eklersiniz. Ölü kod dedektörünüz bu hattın öldüğünü algılarsa, programın durmadığını bilirsiniz. Değilse, programınızın durduğunu bilirsiniz (son satıra ve ardından eklediğiniz kod satırına ulaşır).

Derleyiciler genellikle derleme zamanında kanıtlanabilecek şeyleri kontrol eder. Örneğin, derleme zamanında yanlış olduğu tespit edilebilen koşullara bağımlı bloklar. Veya return(aynı kapsam dahilinde) sonrasındaki herhangi bir ifade .

Bunlar özel durumlar ve bu nedenle onlar için bir algoritma yazmak mümkündür. Daha karmaşık vakalar için algoritmalar yazmak mümkün olabilir (bir koşulun sözdizimsel olarak bir çelişki olup olmadığını kontrol eden ve bu nedenle her zaman yanlış döndürülecek bir algoritma gibi), ancak yine de olası tüm durumları kapsamaz.

Durma probleminin kararsızlığının klasik kanıtını alalım ve durma dedektörünü bir ölü kod detektörüne değiştirelim!

C # programı

using System;
using YourVendor.Compiler;

class Program
{
    static void Main(string[] args)
    {
        string quine_text = @"using System;
using YourVendor.Compiler;

class Program
{{
    static void Main(string[] args)
    {{
        string quine_text = @{0}{1}{0};
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {{
            System.Console.WriteLine({0}Dead code!{0});
        }}
    }}
}}";
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {
            System.Console.WriteLine("Dead code!");
        }
    }
}

Eğer YourVendor.Compiler.HasDeadCode(quine_text)getiri false, daha sonra hat System.Console.WriteLn("Dead code!");bu program aslında çok hiç yürütülmez gelmez ölü kodu var ve dedektör yanlıştı.

Ancak geri dönerse true, satır System.Console.WriteLn("Dead code!");yürütülür ve programda daha fazla kod olmadığından, hiç ölü kod yoktur, bu yüzden tekrar dedektör yanlıştı.

İşte orada, sadece "Ölü kod var" veya "Ölü kod yok" döndüren bir ölü kod dedektörü bazen yanlış cevaplar vermelidir.

Durma problemi çok belirsiz ise, bu şekilde düşünün.

Tüm pozitif tamsayıların n için doğru olduğuna inanılan , ancak her n için doğru olduğu kanıtlanmayan bir matematik problemi alın . Buna iyi bir örnek, Goldbach'ın ikiden büyük herhangi bir pozitif tamsayının iki asalın toplamı ile temsil edilebileceği iddiasıdır. Sonra (uygun bir bigint kütüphanesi ile) bu programı çalıştırın (pseudocode aşağıdaki gibidir):

 for (BigInt n = 4; ; n+=2) {
     if (!isGoldbachsConjectureTrueFor(n)) {
         print("Conjecture is false for at least one value of n\n");
         exit(0);
     }
 }

Uygulanması isGoldbachsConjectureTrueFor(), okuyucu için bir alıştırma olarak bırakılmıştır, ancak bu amaçla,n

Şimdi, mantıksal olarak yukarıdakilerin ikisine de eşit olması gerekir:

 for (; ;) {
 }

(yani sonsuz bir döngü) veya

print("Conjecture is false for at least one value of n\n");

çünkü Goldbach'ın varsayımı ya doğru ya da doğru olmamalıdır. Bir derleyici her zaman ölü kodu ortadan kaldırabilseydi, her iki durumda da ortadan kaldırmak için kesinlikle ölü kod olurdu. Ancak bunu yaparken en azından derleyicinizin keyfi olarak zor sorunları çözmesi gerekir. Biz sorunları sağlayabilir kanıtlanabilir sert kodun biraz ortadan kaldırmak için hangi belirlemek için (örneğin NP-tam problemleri) çözmek zorunda kalacağını. Örneğin bu programı alırsak:

 String target = "f3c5ac5a63d50099f3b5147cabbbd81e89211513a92e3dcd2565d8c7d302ba9c";
 for (BigInt n = 0; n < 2**2048; n++) {
     String s = n.toString();
     if (sha256(s).equals(target)) {
         print("Found SHA value\n");
         exit(0);
     }
 }
 print("Not found SHA value\n");

programın "Bulunan SHA değeri" veya "Bulunmayan SHA değeri" (hangisinin doğru olduğunu söyleyebilirseniz bonus puanları) yazdıracağını biliyoruz. Ancak, bir derleyicinin 2 ^ 2048 yineleme sırasını alacak şekilde makul bir şekilde optimize edebilmesi için. Aslında, yukarıdaki programın herhangi bir optimizasyon olmadan herhangi bir şey basmak yerine evrenin ısı ölümüne kadar çalışacağını (ya da çalışabileceğini) tahmin ettiğim için büyük bir optimizasyon olurdu.

C ++ veya Java'nın bir Evaltür işlevi olup olmadığını bilmiyorum , ancak birçok dil adıyla çağrı yöntemlerini yapmanıza izin veriyor . Aşağıdaki (kabul edilmiş) VBA örneğini düşünün.

Dim methodName As String

If foo Then
    methodName = "Bar"
Else
    methodName = "Qux"
End If

Application.Run(methodName)

Çağrılacak yöntemin adını çalışma zamanına kadar bilmek mümkün değildir. Bu nedenle, tanım olarak, derleyici, belirli bir yöntemin asla çağrılmadığını kesin olarak kesin olarak bilemez.

Aslında, bir yöntemi isimle çağırmak örneği verildiğinde, dallanma mantığı bile gerekli değildir. Basitçe söylemek gerekirse

Application.Run("Bar")

Derleyicinin belirleyebileceğinden daha fazla. Kod derlendiğinde, tüm derleyici bu yönteme belirli bir dize değerinin iletildiğini bilir. Bu yöntemin çalışma zamanına kadar var olup olmadığını kontrol etmez. Yöntem başka bir yerde çağrılmazsa, daha normal yöntemlerle, ölü yöntemleri bulma girişimi yanlış pozitifler döndürebilir. Aynı sorun, kodun yansıma yoluyla çağrılmasını sağlayan herhangi bir dilde de mevcuttur.

Koşulsuz ölü kod gelişmiş derleyiciler tarafından algılanabilir ve kaldırılabilir.

Ancak şartlı ölü kod da vardır. Bu, derleme sırasında bilinemeyen ve yalnızca çalışma zamanı sırasında algılanabilen koddur. Örneğin, bir yazılım, kullanıcı tercihine bağlı olarak belirli özellikleri içerecek veya hariç tutacak şekilde yapılandırılabilir ve kodun belirli bölümlerinin belirli senaryolarda ölü gibi görünmesini sağlar. Bu gerçek ölü kod değil.

Verimlilik için test yapabilen, bağımlılıkları çözebilen, koşullu ölü kodu kaldırabilen ve yararlı kodu çalışma zamanında yeniden birleştirebilen özel araçlar vardır. Buna dinamik ölü kod eliminasyonu denir. Ama gördüğünüz gibi derleyicilerin kapsamı dışında.

Basit bir örnek:

int readValueFromPort(const unsigned int portNum);

int x = readValueFromPort(0x100); // just an example, nothing meaningful
if (x < 2)
{
    std::cout << "Hey! X < 2" << std::endl;
}
else
{
    std::cout << "X is too big!" << std::endl;
}

Şimdi 0x100 bağlantı noktasının yalnızca 0 veya 1 döndürecek şekilde tasarlandığını varsayın. Bu durumda derleyici elsebloğun hiçbir zaman yürütülmeyeceğini anlayamaz .

Ancak bu temel örnekte:

bool boolVal = /*anything boolean*/;

if (boolVal)
{
  // Do A
}
else if (!boolVal)
{
  // Do B
}
else
{
  // Do C
}

Burada derleyici elsebloğun ölü bir kod olduğunu hesaplayabilir . Böylece derleyici ölü kod hakkında ancak ölü kodu anlamaya yetecek kadar veri varsa ve verilen bloğun ölü kod olup olmadığını anlamak için bu verilerin nasıl uygulanacağını bilmelidir.

DÜZENLE

Bazen veriler derleme zamanında kullanılamaz:

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

if (boolVal)
{
  // Do A
}
else
{
  // Do B
}

//............
// File b.cpp
bool boolMethod()
{
    return true;
}

A.cpp derlenirken derleyici boolMethodher zaman geri döndüğünü bilemez true.

Derleyici her zaman bazı bağlam bilgilerine sahip olmayacaktır. Örneğin, bir çift değerin asla 2'yi aşmadığını biliyorsunuz, çünkü bu matematiksel işlevin bir özelliği, bir kütüphaneden kullanıyorsunuz. Derleyici kodu kütüphanede bile görmez ve tüm matematiksel işlevlerin tüm özelliklerini asla bilemez ve bunları uygulamak için tüm garip ve karmaşık yolları tespit edemez.

Derleyici tüm programı mutlaka görmez. Paylaşılan kitaplığı çağıran bir programım olabilir, bu da programımda doğrudan çağrılmayan bir işleve geri döner.

Dolayısıyla, derlendiği kitaplıkla ilgili ölü bir işlev, çalışma zamanında bu kitaplığın değiştirilmesi durumunda canlanabilir.

Bir derleyici tüm ölü kodları doğru bir şekilde ortadan kaldırabilirse, buna tercüman denir .

Bu basit senaryoyu düşünün:

if (my_func()) {
  am_i_dead();
}

my_func() rastgele kod içerebilir ve derleyicinin doğru veya yanlış döndürüp döndürmediğini belirlemesi için kodu çalıştırması veya kodu çalıştırmaya işlevsel olarak eşdeğer bir şey yapması gerekir.

Bir derleyici fikri, kodun sadece kısmi bir analizini gerçekleştirerek ayrı bir çalışma ortamının işini basitleştirmesidir. Tam bir analiz yaparsanız, bu artık bir derleyici değildir.

Derleyiciyi bir işlev c(), nerede c(source)=compiled codeve çalışma ortamını r(), nerede olarak r(compiled code)=program outputgörürseniz, değerini hesaplamanız gereken herhangi bir kaynak kodunun çıktısını belirlemek için r(c(source code)). Hesaplama Eğer c()değerinin bilinmesini gerektirir r(c())herhangi bir giriş için ayrı bir gerek yoktur r()ve c(): Eğer bir işlev türetmek sadece olabilir i()dan c()öyle ki i(source)=program output.

Diğerleri durma problemi ve benzerleri hakkında yorum yaptı. Bunlar genellikle fonksiyon kısımları için geçerlidir. Ancak, tüm bir türün (sınıf / vb.) Bile kullanılıp kullanılmadığını bilmek zor / imkansız olabilir.

.NET / Java / JavaScript ve diğer çalışma zamanı güdümlü ortamlarda yansıma yoluyla yüklenecek durdurma türleri yoktur. Bu, bağımlılık enjeksiyon çerçeveleri ile popülerdir ve serileştirme veya dinamik modül yükleme karşısında akıl yürütmek daha da zordur.

Derleyici bu tür türlerin yüklenip yüklenmeyeceğini bilemez. İsimleri olabilir zamanında harici yapılandırma dosyalarından gelir.

Kullanılmayan kod alt bölümlerini güvenli bir şekilde kaldırmaya çalışan araçlar için yaygın bir terim olan ağaç sallayarak aramak isteyebilirsiniz .

Bir işlev al

void DoSomeAction(int actnumber) 
{
    switch(actnumber) 
    {
        case 1: Action1(); break;
        case 2: Action2(); break;
        case 3: Action3(); break;
    }
}

Bunu kanıtlamak Can actnumberasla 2böylece Action2()asla denir ...?

Durma sorununa katılmıyorum. Gerçekte asla ulaşılamayacak olmasına rağmen böyle bir kodu ölü demezdim.

Bunun yerine şunu düşünelim:

for (int N = 3;;N++)
  for (int A = 2; A < int.MaxValue; A++)
    for (int B = 2; B < int.MaxValue; B++)
    {
      int Square = Math.Pow(A, N) + Math.Pow(B, N);
      float Test = Math.Sqrt(Square);
      if (Test == Math.Trunc(Test))
        FermatWasWrong();
    }

private void FermatWasWrong()
{
  Press.Announce("Fermat was wrong!");
  Nobel.Claim();
}

(Tür ve taşma hatalarını dikkate almayın) Ölü kod?

Şu örneğe bakın:

public boolean isEven(int i){

    if(i % 2 == 0)
        return true;
    if(i % 2 == 1)
        return false;
    return false;
}

Derleyici bir int'in çift veya tek olabileceğini bilemez. Bu nedenle derleyici kodunuzun anlamını anlayabilmelidir. Bu nasıl uygulanmalı? Derleyici, en düşük getirinin asla yürütülmeyeceğinden emin olamaz. Bu nedenle derleyici ölü kodu algılayamaz.