ทำไมคอมไพเลอร์ตรวจไม่พบเดดโค้ดจึงไม่สามารถแก้ไขได้อย่างสมบูรณ์?

คอมไพเลอร์ที่ฉันใช้ใน C หรือ Java มีการป้องกันโค้ดที่ตายแล้ว (คำเตือนเมื่อไม่มีการประมวลผลบรรทัด) อาจารย์ของฉันบอกว่าปัญหานี้ไม่สามารถแก้ไขได้อย่างสมบูรณ์โดยคอมไพเลอร์ ฉันสงสัยว่าทำไม ฉันไม่คุ้นเคยกับการเขียนโปรแกรมคอมไพเลอร์จริง ๆ เพราะนี่เป็นคลาสที่อิงตามทฤษฎี แต่ฉันสงสัยว่าสิ่งที่พวกเขาตรวจสอบ (เช่นสตริงอินพุตที่เป็นไปได้เทียบกับอินพุตที่ยอมรับได้ ฯลฯ ) และสาเหตุที่ไม่เพียงพอ

ปัญหาโค้ดเดดซีเกี่ยวข้องกับ ปัญหาลังเล

Alan Turing พิสูจน์แล้วว่าเป็นไปไม่ได้ที่จะเขียนอัลกอริธึมทั่วไปที่จะได้รับโปรแกรมและสามารถตัดสินใจได้ว่าโปรแกรมนั้นจะหยุดทำงานสำหรับอินพุตทั้งหมดหรือไม่ คุณอาจจะสามารถเขียนอัลกอริทึมดังกล่าวสำหรับโปรแกรมเฉพาะบางประเภท แต่ไม่สามารถใช้ได้กับทุกโปรแกรม

สิ่งนี้เกี่ยวข้องกับโค้ดที่ตายแล้วอย่างไร

ลังเลปัญหาคือซึ้งทำให้การแก้ไขปัญหาของการหารหัสตาย นั่นคือถ้าคุณพบอัลกอริทึมที่สามารถตรวจจับโค้ดที่ตายแล้วในโปรแกรมใด ๆคุณสามารถใช้อัลกอริทึมนั้นเพื่อทดสอบว่าโปรแกรมใดจะหยุดทำงานหรือไม่ ตั้งแต่ที่ได้รับการพิสูจน์แล้วว่าเป็นไปไม่ได้มันตามมาด้วยการเขียนอัลกอริธึมสำหรับรหัสที่ตายแล้วก็เป็นไปไม่ได้เช่นกัน

คุณจะถ่ายโอนอัลกอริทึมสำหรับเดดโค้ดเข้าสู่อัลกอริทึมสำหรับปัญหาการหยุดงานได้อย่างไร

ง่าย: คุณเพิ่มบรรทัดของรหัสหลังจากสิ้นสุดโปรแกรมที่คุณต้องการตรวจสอบหยุด หากเครื่องตรวจจับรหัสตายตัวของคุณตรวจพบว่าบรรทัดนี้ตายแล้วคุณจะรู้ว่าโปรแกรมไม่หยุด หากไม่เป็นเช่นนั้นคุณจะรู้ว่าโปรแกรมของคุณหยุดทำงาน (ไปที่บรรทัดสุดท้ายแล้วไปยังบรรทัดโค้ดที่เพิ่มเข้ามา)

คอมไพเลอร์มักตรวจสอบสิ่งต่าง ๆ ที่สามารถพิสูจน์ได้ในเวลารวบรวมเพื่อให้ตาย ตัวอย่างเช่นบล็อกที่ขึ้นอยู่กับเงื่อนไขที่สามารถพิจารณาได้ว่าเป็นเท็จในเวลารวบรวม หรือข้อความใด ๆ หลังจากreturn(ภายในขอบเขตเดียวกัน)

กรณีเหล่านี้เป็นกรณีเฉพาะและดังนั้นจึงเป็นไปได้ที่จะเขียนอัลกอริทึมสำหรับพวกเขา อาจเป็นไปได้ที่จะเขียนอัลกอริธึมสำหรับกรณีที่ซับซ้อนมากขึ้น (เช่นอัลกอริทึมที่ตรวจสอบว่าเงื่อนไขนั้นขัดแย้งกันหรือไม่และมักจะกลับเท็จ) แต่ยังคงไม่ครอบคลุมกรณีที่เป็นไปได้ทั้งหมด

ทีนี้ลองมาพิสูจน์ข้อผิดพลาดแบบดั้งเดิมของความลังเลของปัญหาการหยุดชะงักและเปลี่ยนตัวตรวจจับการลังเลไปเป็นเครื่องตรวจจับรหัสตาย!

โปรแกรม 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!");
        }
    }
}

ถ้า YourVendor.Compiler.HasDeadCode(quine_text)ส่งคืนจะไม่มีการดำเนินการfalseบรรทัดSystem.Console.WriteLn("Dead code!");ดังนั้นโปรแกรมนี้จึงมีรหัสตายตัวและเครื่องมือตรวจจับผิด

แต่ถ้ามันกลับtrueมาบรรทัดSystem.Console.WriteLn("Dead code!");จะถูกดำเนินการและเนื่องจากไม่มีรหัสเพิ่มเติมในโปรแกรมจึงไม่มีรหัสตายเลยดังนั้นอีกครั้งเครื่องตรวจจับก็ผิด

ดังนั้นคุณก็มีเครื่องตรวจจับรหัสตายตัวที่ส่งกลับเฉพาะ "ไม่มีรหัสตาย" หรือ "ไม่มีรหัสตาย" บางครั้งต้องตอบคำตอบที่ผิด

หากปัญหาการหยุดชะงักไม่ชัดเจนเกินไปให้คิดแบบนี้

รับปัญหาทางคณิตศาสตร์ที่เชื่อว่าจะเป็นจริงสำหรับทุกจำนวนเต็มบวกของnแต่ยังไม่ได้รับการพิสูจน์แล้วว่าเป็นจริงสำหรับทุกn ตัวอย่างที่ดีคือการคาดคะเนของ Goldbachว่าจำนวนเต็มบวกใด ๆ ที่มากกว่าสองจะแสดงด้วยผลบวกของจำนวนเฉพาะสองช่วง จากนั้น (ด้วยไลบรารีขนาดใหญ่ที่เหมาะสม) ให้เรียกใช้โปรแกรมนี้ (pseudocode ดังนี้):

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

การดำเนินการของisGoldbachsConjectureTrueFor()เหลือเป็นแบบฝึกหัดสำหรับผู้อ่าน แต่เพื่อจุดประสงค์นี้อาจซ้ำง่ายกว่าทุกช่วงเวลาน้อยกว่าn

ทีนี้เหตุผลข้างต้นต้องเท่ากับ:

 for (; ;) {
 }

(เช่นวงวนไม่สิ้นสุด) หรือ

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

การคาดคะเนของ Goldbach จะต้องเป็นจริงหรือไม่จริง หากคอมไพเลอร์สามารถกำจัดรหัสที่ตายแล้วจะมีรหัสตายตัวแน่นอนที่จะกำจัดที่นี่ในทั้งสองกรณี อย่างไรก็ตามในการทำเช่นนั้นอย่างน้อยที่สุดคอมไพเลอร์ของคุณจะต้องแก้ปัญหายากโดยพลการ เราสามารถให้ปัญหาที่พิสูจน์ได้ยากว่าจะต้องแก้ปัญหา (เช่นปัญหา NP-complete) เพื่อกำหนดบิตของโค้ดที่จะกำจัด เช่นถ้าเราใช้โปรแกรมนี้:

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

เรารู้ว่าโปรแกรมจะพิมพ์ "Found SHA value" หรือ "Not Found SHA value" (คะแนนโบนัสถ้าคุณสามารถบอกได้ว่าอันไหนเป็นจริง) อย่างไรก็ตามสำหรับคอมไพเลอร์ที่จะสามารถเพิ่มประสิทธิภาพที่เหมาะสมที่จะใช้คำสั่งของการทำซ้ำ 2 ^ 2048 ในความเป็นจริงมันจะเป็นการเพิ่มประสิทธิภาพที่ดีที่สุดเท่าที่ฉันคาดการณ์โปรแกรมข้างต้นจะ (หรืออาจ) ทำงานจนกว่าความร้อนจากจักรวาลมากกว่าการพิมพ์อะไรโดยไม่มีการเพิ่มประสิทธิภาพ

ผมไม่ทราบว่าถ้า C ++ หรือ Java มีEvalฟังก์ชั่นประเภท แต่หลายภาษาจะช่วยให้คุณทำวิธีการโทรโดยใช้ชื่อ พิจารณาตัวอย่าง VBA (ที่วางแผน) ต่อไปนี้

Dim methodName As String

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

Application.Run(methodName)

ชื่อของวิธีการที่จะเรียกนั้นเป็นไปไม่ได้ที่จะรู้จนกว่าจะถึงจริง ดังนั้นตามคำนิยามคอมไพเลอร์ไม่สามารถรู้ได้ด้วยความมั่นใจแน่นอนว่าวิธีการเฉพาะไม่เคยถูกเรียก

ตามจริงแล้วตัวอย่างของการเรียกใช้เมธอดด้วยชื่อตรรกะการแตกสาขาไม่จำเป็นต้องมีแม้แต่ เพียงแค่พูดว่า

Application.Run("Bar")

เป็นมากกว่าที่คอมไพเลอร์สามารถกำหนดได้ เมื่อโค้ดถูกคอมไพล์เลอร์ทั้งหมดจะรู้ว่าค่าสตริงที่แน่นอนถูกส่งผ่านไปยังเมธอดนั้น มันไม่ได้ตรวจสอบเพื่อดูว่าวิธีการที่มีอยู่จนกระทั่งรันไทม์ หากวิธีนั้นไม่ได้ถูกเรียกที่อื่นผ่านวิธีการทั่วไปที่มากขึ้นความพยายามในการค้นหาวิธีการที่ตายแล้วสามารถส่งคืนผลบวกปลอมได้ ปัญหาเดียวกันนี้มีอยู่ในภาษาใด ๆ ที่อนุญาตให้โค้ดถูกเรียกผ่านการสะท้อนกลับ

โค้ดที่ไม่มีเงื่อนไขสามารถตรวจจับและลบโดยคอมไพเลอร์ขั้นสูง

แต่ก็ยังมีรหัสตายตามเงื่อนไข นั่นคือรหัสที่ไม่สามารถทราบได้ในเวลาที่รวบรวมและสามารถตรวจพบได้เฉพาะในช่วงรันไทม์ ตัวอย่างเช่นซอฟต์แวร์อาจกำหนดค่าให้รวมหรือไม่รวมคุณลักษณะบางอย่างขึ้นอยู่กับการตั้งค่าของผู้ใช้ทำให้บางส่วนของรหัสดูเหมือนตายในบางสถานการณ์ นั่นไม่ใช่รหัสตายจริง

มีเครื่องมือเฉพาะที่สามารถทำการทดสอบแก้ไขการอ้างอิงลบรหัสที่ไม่มีเงื่อนไขและรวมรหัสที่เป็นประโยชน์ในการใช้งานจริงเพื่อประสิทธิภาพ สิ่งนี้เรียกว่าการกำจัดรหัสตายแบบไดนามิก แต่อย่างที่คุณเห็นมันเกินขอบเขตของคอมไพเลอร์

ตัวอย่างง่ายๆ:

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

ตอนนี้สมมติว่าพอร์ต 0x100 ได้รับการออกแบบให้คืนค่าเป็น 0 หรือ 1 เท่านั้นในกรณีนี้คอมไพเลอร์ไม่สามารถคิดได้ว่าelseบล็อกจะไม่ถูกดำเนินการ

อย่างไรก็ตามในตัวอย่างพื้นฐานนี้:

bool boolVal = /*anything boolean*/;

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

ที่นี่คอมไพเลอร์สามารถคำนวณได้ว่าelseบล็อกนั้นเป็นรหัสตาย ดังนั้นคอมไพเลอร์สามารถเตือนเกี่ยวกับรหัสตายตัวเฉพาะในกรณีที่มีข้อมูลเพียงพอที่จะคำนวณรหัสตายตัวและควรรู้วิธีการใช้ข้อมูลนั้นเพื่อที่จะทราบว่าบล็อกที่กำหนดนั้นเป็นรหัสตาย

แก้ไข

บางครั้งข้อมูลไม่สามารถใช้ได้ในเวลารวบรวม:

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

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

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

ขณะคอมไพล์ a.cpp คอมไพเลอร์ไม่สามารถรู้ได้ boolMethodtrueมักกลับมาเสมอ

คอมไพเลอร์มักจะขาดข้อมูลบริบทบางอย่าง เช่นคุณอาจรู้ว่าค่าสองเท่าไม่เคยเกิน 2 เนื่องจากเป็นคุณลักษณะของฟังก์ชันทางคณิตศาสตร์คุณจึงใช้จากไลบรารี คอมไพเลอร์ไม่เห็นรหัสในไลบรารีและไม่สามารถรู้คุณลักษณะทั้งหมดของฟังก์ชันทางคณิตศาสตร์ทั้งหมดและตรวจหาวิธีที่ซับซ้อนและซับซ้อนเพื่อนำไปใช้งาน

คอมไพเลอร์ไม่จำเป็นต้องเห็นโปรแกรมทั้งหมด ฉันสามารถมีโปรแกรมที่เรียกไลบรารีที่ใช้ร่วมกันซึ่งโทรกลับไปที่ฟังก์ชันในโปรแกรมของฉันซึ่งไม่ได้เรียกโดยตรง

ดังนั้นฟังก์ชั่นที่เสียชีวิตเมื่อเทียบกับไลบรารีที่รวบรวมไว้อาจมีชีวิตถ้าห้องสมุดนั้นเปลี่ยนไปในขณะใช้งาน

ถ้าคอมไพเลอร์สามารถกำจัดรหัสตายทุกอย่างถูกต้องก็จะได้ชื่อว่าเป็นล่าม

พิจารณาสถานการณ์ง่าย ๆ นี้:

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

my_func() สามารถมีรหัสโดยพลการและเพื่อให้คอมไพเลอร์ตรวจสอบว่ามันคืนจริงหรือเท็จก็จะต้องเรียกใช้รหัสหรือทำสิ่งที่เทียบเท่ากับการใช้งานรหัส

แนวคิดของคอมไพเลอร์คือมันทำการวิเคราะห์บางส่วนของรหัสเท่านั้นซึ่งทำให้งานของสภาพแวดล้อมการทำงานแยกจากกันง่ายขึ้น หากคุณทำการวิเคราะห์เต็มรูปแบบนั่นไม่ใช่คอมไพเลอร์อีกต่อไป

หากคุณพิจารณาคอมไพเลอร์เป็นฟังก์ชั่น c()ที่c(source)=compiled codeและสภาพแวดล้อมในการทำงานตามr()ที่แล้วเพื่อตรวจสอบการส่งออกรหัสที่มาที่คุณต้องคำนวณค่าของr(compiled code)=program output r(c(source code))หากการคำนวณc()ต้องการความรู้เกี่ยวกับค่าของr(c())อินพุตใด ๆ ก็ไม่จำเป็นต้องแยกจากกันr()และc()คุณสามารถรับฟังก์ชั่นi()จากc()สิ่งนั้นi(source)=program outputได้

คนอื่น ๆ ให้ความเห็นเกี่ยวกับปัญหาการหยุดชะงักและอื่น ๆ โดยทั่วไปจะใช้กับบางส่วนของฟังก์ชั่น อย่างไรก็ตามมันอาจเป็นเรื่องยาก / เป็นไปไม่ได้ที่จะรู้ว่าแม้จะใช้ทั้งประเภท (คลาส / ฯลฯ ) หรือไม่ก็ตาม

ใน. NET / Java / JavaScript และสภาพแวดล้อมที่ขับเคลื่อนด้วยรันไทม์อื่น ๆ จะไม่มีการหยุดการโหลดประเภทใด ๆ ผ่านการสะท้อนกลับ สิ่งนี้ได้รับความนิยมจากเฟรมเวิร์กการฉีดแบบพึ่งพาและยิ่งยากที่จะให้เหตุผลเมื่อเผชิญกับการ deserialisation หรือการโหลดโมดูลแบบไดนามิก

คอมไพเลอร์ไม่ทราบว่าจะโหลดประเภทนี้หรือไม่ ชื่อของพวกเขาอาจมาจากไฟล์ปรับแต่งภายนอกที่รันไทม์

คุณอาจต้องการค้นหาการเขย่าต้นไม้ซึ่งเป็นคำทั่วไปสำหรับเครื่องมือที่พยายามลบกราฟย่อยของรหัสที่ไม่ได้ใช้อย่างปลอดภัย

ใช้ฟังก์ชั่น

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

คุณสามารถพิสูจน์ได้ว่าactnumberจะไม่เป็น2อย่างนั้นอย่างที่Action2()ไม่เคยถูกเรียกว่า ... ?

ฉันไม่เห็นด้วยกับปัญหาการหยุดชะงัก ฉันจะไม่เรียกรหัสนั้นว่าตายแม้ว่าในความเป็นจริงมันจะไม่สามารถเข้าถึงได้

ให้ลองพิจารณา:

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

(ละเว้นข้อผิดพลาดประเภทและการโอเวอร์โฟลว์) รหัสที่ผิดพลาดหรือไม่

ดูตัวอย่างนี้:

public boolean isEven(int i){

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

คอมไพเลอร์ไม่สามารถรู้ได้ว่า int สามารถเป็นเลขคู่หรือคี่เท่านั้น ดังนั้นคอมไพเลอร์จะต้องสามารถเข้าใจความหมายของรหัสของคุณ สิ่งนี้ควรนำไปปฏิบัติอย่างไร คอมไพเลอร์ไม่สามารถมั่นใจได้ว่าผลตอบแทนต่ำสุดจะไม่ถูกดำเนินการ ดังนั้นคอมไพเลอร์ไม่สามารถตรวจพบโค้ดที่ตายแล้ว