Tại sao phát hiện mã chết không thể được giải quyết hoàn toàn bởi trình biên dịch?

Các trình biên dịch mà tôi đang sử dụng trong C hoặc Java có chức năng ngăn chặn mã chết (cảnh báo khi một dòng sẽ không được thực thi). Giáo sư của tôi nói rằng vấn đề này không bao giờ có thể được giải quyết hoàn toàn bằng trình biên dịch. Tôi đã tự hỏi tại sao đó là. Tôi không quá quen thuộc với mã hóa thực tế của trình biên dịch vì đây là lớp dựa trên lý thuyết. Nhưng tôi đã tự hỏi những gì họ kiểm tra (chẳng hạn như chuỗi đầu vào có thể so với đầu vào chấp nhận được, v.v.) và tại sao điều đó là không đủ.

Vấn đề mã chết có liên quan đến vấn đề Dừng .

Alan Turing đã chứng minh rằng không thể viết một thuật toán chung sẽ được cung cấp một chương trình và có thể quyết định liệu chương trình đó có dừng lại cho tất cả các đầu vào hay không. Bạn có thể viết một thuật toán như vậy cho các loại chương trình cụ thể, nhưng không phải cho tất cả các chương trình.

Làm thế nào điều này liên quan đến mã chết?

Vấn đề Dừng có thể giảm bớt đối với vấn đề tìm mã chết. Đó là, nếu bạn tìm thấy một thuật toán có thể phát hiện mã chết trong bất kỳ chương trình nào , thì bạn có thể sử dụng thuật toán đó để kiểm tra xem có chương trình nào dừng lại không. Vì điều đó đã được chứng minh là không thể, nên theo sau đó, việc viết một thuật toán cho mã chết là không thể.

Làm thế nào để bạn chuyển một thuật toán cho mã chết thành một thuật toán cho vấn đề Dừng?

Đơn giản: bạn thêm một dòng mã sau khi kết thúc chương trình bạn muốn kiểm tra tạm dừng. Nếu trình phát hiện mã chết của bạn phát hiện ra rằng dòng này đã chết, thì bạn biết rằng chương trình không dừng lại. Nếu không, thì bạn biết rằng chương trình của bạn tạm dừng (đến dòng cuối cùng, và sau đó đến dòng mã được thêm vào của bạn).

Trình biên dịch thường kiểm tra những thứ có thể được chứng minh tại thời điểm biên dịch là đã chết. Ví dụ, các khối phụ thuộc vào các điều kiện có thể được xác định là sai tại thời điểm biên dịch. Hoặc bất kỳ tuyên bố nào sau một return(trong cùng phạm vi).

Đây là những trường hợp cụ thể và do đó có thể viết một thuật toán cho chúng. Có thể viết thuật toán cho các trường hợp phức tạp hơn (như thuật toán kiểm tra xem một điều kiện có phải là mâu thuẫn về mặt cú pháp hay không và do đó sẽ luôn trả về sai), nhưng vẫn không bao gồm tất cả các trường hợp có thể.

Chà, hãy lấy bằng chứng cổ điển về tính không ổn định của vấn đề tạm dừng và thay đổi máy dò tạm dừng thành máy dò mã chết!

Chương trình C #

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!");
        }
    }
}

Nếu YourVendor.Compiler.HasDeadCode(quine_text)lợi nhuận false, sau đó dòng System.Console.WriteLn("Dead code!");sẽ không được bao giờ thực hiện, vì vậy chương trình này thực sự không có mã chết, và các máy dò đã sai.

Nhưng nếu nó trả về true, thì dòng System.Console.WriteLn("Dead code!");sẽ được thực thi và vì không có thêm mã trong chương trình, nên không có mã chết nào cả, vì vậy một lần nữa, trình phát hiện đã sai.

Vì vậy, bạn có nó, một trình phát hiện mã chết chỉ trả về "Có mã chết" hoặc "Không có mã chết" đôi khi phải đưa ra câu trả lời sai.

Nếu vấn đề tạm dừng quá mơ hồ, hãy nghĩ về nó theo cách này.

Đi một vấn đề toán học mà được tin là đúng đối với tất cả các số nguyên dương của n , nhưng chưa được chứng minh là đúng đối với mỗi n . Một ví dụ điển hình sẽ là phỏng đoán của Goldbach , rằng bất kỳ số nguyên dương nào lớn hơn hai có thể được biểu diễn bằng tổng của hai số nguyên tố. Sau đó (với một thư viện bigint thích hợp) chạy chương trình này (mã giả theo sau):

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

Việc thực hiện isGoldbachsConjectureTrueFor()được để lại như một bài tập cho người đọc nhưng với mục đích này có thể là một phép lặp đơn giản trên tất cả các số nguyên tố ít hơnn

Bây giờ, về mặt logic ở trên phải tương đương với:

 for (; ;) {
 }

(tức là một vòng lặp vô hạn) hoặc

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

theo phỏng đoán của Goldbach phải đúng hoặc không đúng. Nếu một trình biên dịch luôn có thể loại bỏ mã chết, chắc chắn sẽ có mã chết để loại bỏ ở đây trong cả hai trường hợp. Tuy nhiên, khi làm như vậy ít nhất trình biên dịch của bạn sẽ cần phải giải quyết các vấn đề khó khăn tùy ý. Chúng tôi có thể cung cấp những vấn đề có thể chứng minh khó khăn mà nó sẽ phải giải quyết (vấn đề ví dụ như NP-đầy đủ) để xác định chút mã để loại bỏ. Ví dụ: nếu chúng tôi thực hiện chương trình này:

 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");

chúng tôi biết rằng chương trình sẽ in ra "Giá trị SHA được tìm thấy" hoặc "Không tìm thấy giá trị SHA" (điểm thưởng nếu bạn có thể cho tôi biết cái nào là đúng). Tuy nhiên, để một trình biên dịch có thể tối ưu hóa một cách hợp lý sẽ có thứ tự lặp lại 2 ^ 2048. Thực tế nó sẽ là một sự tối ưu hóa tuyệt vời khi tôi dự đoán chương trình trên sẽ (hoặc có thể) chạy cho đến khi cái chết nóng của vũ trụ thay vì in bất cứ thứ gì mà không tối ưu hóa.

Tôi không biết nếu C ++ hoặc Java có Evalhàm loại, nhưng nhiều ngôn ngữ cho phép bạn thực hiện các phương thức gọi theo tên . Hãy xem xét ví dụ VBA (giả định) sau đây.

Dim methodName As String

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

Application.Run(methodName)

Tên của phương thức được gọi là không thể biết cho đến khi thời gian chạy. Do đó, theo định nghĩa, trình biên dịch không thể biết chắc chắn rằng một phương thức cụ thể không bao giờ được gọi.

Trên thực tế, được đưa ra ví dụ về cách gọi một phương thức theo tên, logic phân nhánh thậm chí không cần thiết. Nói đơn giản

Application.Run("Bar")

Là nhiều hơn trình biên dịch có thể xác định. Khi mã được biên dịch, tất cả các trình biên dịch đều biết rằng một giá trị chuỗi nhất định đang được truyền cho phương thức đó. Nó không kiểm tra xem phương thức đó có tồn tại cho đến khi runtime không. Nếu phương thức không được gọi ở nơi khác, thông qua các phương thức bình thường hơn, một nỗ lực tìm phương thức chết có thể trả về kết quả dương tính giả. Vấn đề tương tự tồn tại trong bất kỳ ngôn ngữ nào cho phép mã được gọi thông qua sự phản chiếu.

Mã chết vô điều kiện có thể được phát hiện và loại bỏ bởi các trình biên dịch nâng cao.

Nhưng cũng có mã chết có điều kiện. Đó là mã không thể được biết tại thời điểm biên dịch và chỉ có thể được phát hiện trong thời gian chạy. Ví dụ: một phần mềm có thể được cấu hình để bao gồm hoặc loại trừ các tính năng nhất định tùy thuộc vào sở thích của người dùng, làm cho các phần mã nhất định dường như đã chết trong các tình huống cụ thể. Đó không phải là mã chết thực sự.

Có các công cụ cụ thể có thể thực hiện kiểm tra, giải quyết các phụ thuộc, loại bỏ mã chết có điều kiện và kết hợp lại mã hữu ích trong thời gian chạy để đạt hiệu quả. Điều này được gọi là loại bỏ mã chết động. Nhưng như bạn có thể thấy nó nằm ngoài phạm vi của trình biên dịch.

Một ví dụ đơn giản:

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;
}

Bây giờ giả sử rằng cổng 0x100 được thiết kế để chỉ trả về 0 hoặc 1. Trong trường hợp đó, trình biên dịch không thể tìm ra rằng elsekhối sẽ không bao giờ được thực thi.

Tuy nhiên trong ví dụ cơ bản này:

bool boolVal = /*anything boolean*/;

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

Ở đây trình biên dịch có thể tính toán elsekhối là một mã chết. Vì vậy, trình biên dịch có thể cảnh báo về mã chết chỉ khi nó có đủ dữ liệu để tìm ra mã chết và cũng nên biết cách áp dụng dữ liệu đó để tìm ra liệu khối đã cho có phải là mã chết hay không.

BIÊN TẬP

Đôi khi dữ liệu không có sẵn tại thời điểm biên dịch:

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

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

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

Trong khi biên dịch a.cpp, trình biên dịch không thể biết rằng boolMethodluôn trả về true.

Trình biên dịch sẽ luôn thiếu một số thông tin ngữ cảnh. Ví dụ, bạn có thể biết rằng giá trị kép không bao giờ vượt quá 2, vì đó là một tính năng của hàm toán học, bạn sử dụng từ thư viện. Trình biên dịch thậm chí không nhìn thấy mã trong thư viện và nó không bao giờ có thể biết tất cả các tính năng của tất cả các hàm toán học và phát hiện tất cả các cách thức phức tạp và phức tạp để thực hiện chúng.

Trình biên dịch không nhất thiết phải xem toàn bộ chương trình. Tôi có thể có một chương trình gọi một thư viện dùng chung, gọi lại một chức năng trong chương trình của tôi không được gọi trực tiếp.

Vì vậy, một chức năng đã chết đối với thư viện mà nó được biên dịch có thể trở nên sống động nếu thư viện đó bị thay đổi khi chạy.

Nếu một trình biên dịch có thể loại bỏ tất cả mã chết một cách chính xác, nó sẽ được gọi là trình thông dịch .

Hãy xem xét kịch bản đơn giản này:

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

my_func() có thể chứa mã tùy ý và để trình biên dịch xác định xem nó trả về đúng hay sai, nó sẽ phải chạy mã hoặc làm một cái gì đó có chức năng tương đương với việc chạy mã.

Ý tưởng của trình biên dịch là nó chỉ thực hiện phân tích một phần mã, do đó đơn giản hóa công việc của một môi trường chạy riêng biệt. Nếu bạn thực hiện phân tích đầy đủ, đó không còn là trình biên dịch nữa.

Nếu bạn coi trình biên dịch là một hàm c(), ở đâu c(source)=compiled codevà môi trường đang chạy như là r()ở đâu r(compiled code)=program output, thì để xác định đầu ra cho bất kỳ mã nguồn nào bạn phải tính giá trị của r(c(source code)). Nếu việc tính toán c()đòi hỏi kiến ​​thức về giá trị của r(c())bất kỳ đầu vào nào, thì không cần riêng biệt r()và c(): bạn chỉ có thể lấy được một hàm i()từ c()đó i(source)=program output.

Những người khác đã bình luận về vấn đề tạm dừng và vv. Chúng thường áp dụng cho các phần của chức năng. Tuy nhiên, có thể khó / không thể biết liệu thậm chí toàn bộ một loại (lớp / vv) có được sử dụng hay không.

Trong .NET / Java / JavaScript và các môi trường điều khiển thời gian chạy khác, không có kiểu dừng nào được tải thông qua sự phản chiếu. Điều này là phổ biến với các khung tiêm phụ thuộc, và thậm chí còn khó hơn để giải thích khi đối mặt với quá trình khử lưu huỳnh hoặc tải mô-đun động.

Trình biên dịch không thể biết liệu các loại như vậy sẽ được tải. Tên của họ có thể đến từ các tập tin cấu hình bên ngoài trong thời gian chạy.

Bạn có thể muốn tìm kiếm xung quanh cây rung chuyển , đó là một thuật ngữ phổ biến cho các công cụ cố gắng loại bỏ một cách an toàn các sơ đồ mã không sử dụng.

Thực hiện một chức năng

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

Bạn có thể chứng minh rằng actnumbersẽ không bao giờ được 2như vậy mà Action2()không bao giờ được gọi là ...?

Tôi không đồng ý về vấn đề tạm dừng. Tôi sẽ không gọi mã như vậy là chết mặc dù trong thực tế, nó sẽ không bao giờ đạt được.

Thay vào đó, hãy xem xét:

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();
}

(Bỏ qua lỗi loại và lỗi tràn) Mã chết?

Nhìn vào ví dụ này:

public boolean isEven(int i){

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

Trình biên dịch không thể biết rằng một int chỉ có thể là chẵn hoặc lẻ. Do đó, trình biên dịch phải có khả năng hiểu ngữ nghĩa của mã của bạn. Làm thế nào điều này nên được thực hiện? Trình biên dịch không thể đảm bảo rằng lợi nhuận thấp nhất sẽ không bao giờ được thực hiện. Do đó trình biên dịch không thể phát hiện mã chết.