Perché un compilatore non può risolvere completamente il rilevamento di codici non funzionanti?

I compilatori che ho usato in C o Java hanno la prevenzione del codice morto (avviso quando una riga non verrà mai eseguita). Il mio professore afferma che questo problema non può mai essere completamente risolto dai compilatori. Mi chiedevo perché fosse così. Non ho troppa familiarità con l'effettiva codifica dei compilatori poiché si tratta di una classe basata sulla teoria. Ma mi chiedevo cosa controllassero (come possibili stringhe di input vs input accettabili, ecc.) E perché ciò non fosse sufficiente.

Il problema del codice morto è correlato al problema di Halting .

Alan Turing ha dimostrato che è impossibile scrivere un algoritmo generale a cui verrà assegnato un programma ed essere in grado di decidere se quel programma si interrompe per tutti gli input. Potresti essere in grado di scrivere un tale algoritmo per tipi specifici di programmi, ma non per tutti i programmi.

Come si collega questo al codice morto?

Il problema di Halting è riducibile al problema di trovare un codice morto. Cioè, se trovi un algoritmo in grado di rilevare il codice morto in qualsiasi programma, puoi utilizzare tale algoritmo per verificare se un programma si arresterà. Dal momento che è stato dimostrato che è impossibile, ne consegue che è impossibile anche scrivere un algoritmo per codice morto.

Come si trasferisce un algoritmo per codice morto in un algoritmo per il problema di Halting?

Semplice: aggiungi una riga di codice dopo la fine del programma che desideri verificare. Se il tuo rilevatore di codice morto rileva che questa linea è morta, allora sai che il programma non si ferma. In caso contrario, sai che il tuo programma si arresta (arriva all'ultima riga e quindi alla riga di codice aggiunta).

I compilatori di solito verificano la morte di elementi che possono essere dimostrati in fase di compilazione. Ad esempio, blocchi che dipendono da condizioni che possono essere determinate come false al momento della compilazione. O qualsiasi affermazione dopo un return(all'interno dello stesso ambito).

Questi sono casi specifici e quindi è possibile scrivere un algoritmo per loro. Potrebbe essere possibile scrivere algoritmi per casi più complicati (come un algoritmo che controlla se una condizione è sintatticamente una contraddizione e quindi restituirà sempre falso), ma che comunque non coprirebbe tutti i casi possibili.

Bene, prendiamo la classica prova dell'indecidibilità del problema di arresto e cambiamo il rilevatore di arresto in un rilevatore di codice morto!

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

Se YourVendor.Compiler.HasDeadCode(quine_text)ritorna false, poi la linea System.Console.WriteLn("Dead code!");non sarà mai eseguita, quindi questo programma in realtà non hanno codice morto, e il rilevatore era sbagliato.

Ma se ritorna true, allora la riga System.Console.WriteLn("Dead code!");verrà eseguita e poiché non c'è più codice nel programma, non c'è affatto un codice morto, quindi il rivelatore era sbagliato.

Quindi il gioco è fatto, un rilevatore di codice morto che restituisce solo "C'è codice morto" o "Non c'è codice morto" a volte deve dare risposte sbagliate.

Se il problema di arresto è troppo oscuro, pensaci in questo modo.

Prendi un problema matematico che si ritiene sia vero per tutti gli interi positivi n , ma non è stato dimostrato che sia vero per ogni n . Un buon esempio sarebbe la congettura di Goldbach , secondo cui qualsiasi numero intero pari positivo maggiore di due può essere rappresentato dalla somma di due numeri primi. Quindi (con una libreria bigint appropriata) esegui questo programma (segue lo pseudocodice):

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

L'implementazione di isGoldbachsConjectureTrueFor()è lasciata come esercizio per il lettore, ma a questo scopo potrebbe essere una semplice iterazione su tutti i numeri primi di menon

Ora, logicamente, quanto sopra deve essere equivalente a:

 for (; ;) {
 }

(ovvero un ciclo infinito) o

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

poiché la congettura di Goldbach deve essere vera o no. Se un compilatore potesse sempre eliminare il codice morto, ci sarebbe sicuramente un codice morto da eliminare qui in entrambi i casi. Tuttavia, almeno così facendo il compilatore dovrebbe risolvere problemi arbitrariamente difficili. Potremmo fornire problemi dimostrabilmente duro che avrebbe dovuto risolvere i problemi (es NP-completi) per determinare quale porzione di codice per eliminare. Ad esempio se prendiamo questo programma:

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

sappiamo che il programma stamperà "Valore SHA trovato" o "Valore SHA non trovato" (punti bonus se puoi dirmi quale è vero). Tuttavia, affinché un compilatore sia in grado di ottimizzare ragionevolmente ciò richiederebbe l'ordine di 2 ^ 2048 iterazioni. Sarebbe in effetti una grande ottimizzazione poiché prevedo che il programma di cui sopra sarebbe (o potrebbe) funzionare fino alla morte per calore dell'universo piuttosto che stampare qualsiasi cosa senza ottimizzazione.

Non so se C ++ o Java abbiano una Evalfunzione di tipo, ma molte lingue ti permettono di chiamare i metodi per nome . Considera l'esempio VBA seguente (inventato).

Dim methodName As String

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

Application.Run(methodName)

Il nome del metodo da chiamare è impossibile da conoscere fino al runtime. Pertanto, per definizione, il compilatore non può sapere con assoluta certezza che un particolare metodo non viene mai chiamato.

In realtà, dato l'esempio di chiamare un metodo per nome, la logica di ramificazione non è nemmeno necessaria. Sto semplicemente dicendo

Application.Run("Bar")

È più di quanto il compilatore possa determinare. Quando il codice viene compilato, tutto il compilatore sa che un determinato valore di stringa viene passato a quel metodo. Non controlla se quel metodo esiste fino al runtime. Se il metodo non viene chiamato altrove, attraverso metodi più normali, un tentativo di trovare metodi morti può restituire falsi positivi. Lo stesso problema esiste in qualsiasi lingua che consente di chiamare il codice tramite reflection.

Il codice morto incondizionato può essere rilevato e rimosso da compilatori avanzati.

Ma c'è anche un codice morto condizionale. Questo è un codice che non può essere conosciuto al momento della compilazione e può essere rilevato solo durante il runtime. Ad esempio, un software può essere configurabile per includere o escludere determinate funzionalità in base alle preferenze dell'utente, rendendo alcune sezioni di codice apparentemente morte in scenari particolari. Questo non è un vero codice morto.

Esistono strumenti specifici che possono eseguire test, risolvere dipendenze, rimuovere il codice morto condizionale e ricombinare il codice utile in fase di esecuzione per l'efficienza. Questo si chiama eliminazione dinamica del codice morto. Ma come puoi vedere, va oltre lo scopo dei compilatori.

Un semplice esempio:

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

Ora supponiamo che la porta 0x100 sia progettata per restituire solo 0 o 1. In quel caso il compilatore non può capire che il elseblocco non verrà mai eseguito.

Tuttavia, in questo esempio di base:

bool boolVal = /*anything boolean*/;

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

Qui il compilatore può calcolare che il elseblocco è un codice morto. Quindi il compilatore può avvertire del codice morto solo se ha abbastanza dati per capire il codice morto e dovrebbe anche sapere come applicare quei dati per capire se il blocco dato è un codice morto.

MODIFICARE

A volte i dati non sono disponibili al momento della compilazione:

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

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

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

Durante la compilazione di a.cpp il compilatore non può sapere che boolMethodritorna sempre true.

Il compilatore mancherà sempre di alcune informazioni di contesto. Ad esempio, potresti sapere che un doppio valore non supera mai 2, poiché questa è una caratteristica della funzione matematica, che usi da una libreria. Il compilatore non vede nemmeno il codice nella libreria e non può mai conoscere tutte le caratteristiche di tutte le funzioni matematiche e rilevare tutti i modi complessi e complicati per implementarli.

Il compilatore non vede necessariamente l'intero programma. Potrei avere un programma che chiama una libreria condivisa, che richiama una funzione nel mio programma che non viene chiamata direttamente.

Quindi una funzione che è morta rispetto alla libreria contro cui è stata compilata potrebbe diventare viva se quella libreria fosse cambiata in fase di esecuzione.

Se un compilatore potesse eliminare accuratamente tutti i codici morti, verrebbe chiamato un interprete .

Considera questo semplice scenario:

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

my_func() può contenere codice arbitrario e affinché il compilatore possa determinare se restituisce vero o falso, dovrà eseguire il codice o fare qualcosa che sia funzionalmente equivalente all'esecuzione del codice.

L'idea di un compilatore è che esegue solo un'analisi parziale del codice, semplificando così il lavoro di un ambiente di esecuzione separato. Se esegui un'analisi completa, questo non è più un compilatore.

Se si considera il compilatore come una funzione c(), dove c(source)=compiled codee l'ambiente in esecuzione come r(), dove r(compiled code)=program output, quindi per determinare l'output per qualsiasi codice sorgente è necessario calcolare il valore di r(c(source code)). Se il calcolo c()richiede la conoscenza del valore di r(c())per qualsiasi input, non è necessario un separato r()e c(): si può semplicemente derivare una funzione i()da c()tale i(source)=program output.

Altri hanno commentato il problema dell'arresto e così via. Questi si applicano generalmente a porzioni di funzioni. Tuttavia, può essere difficile / impossibile sapere se viene utilizzato o meno un intero tipo (classe / ecc.).

In .NET / Java / JavaScript e altri ambienti basati su runtime non c'è nulla che impedisca il caricamento dei tipi tramite reflection. Questo è popolare tra i framework di iniezione delle dipendenze ed è ancora più difficile da ragionare di fronte alla deserializzazione o al caricamento dinamico dei moduli.

Il compilatore non può sapere se tali tipi verrebbero caricati. I loro nomi potrebbero derivare da file di configurazione esterni in fase di esecuzione.

È possibile che si cerchi di scuotere l'albero, che è un termine comune per strumenti che tentano di rimuovere in modo sicuro i sottogrammi di codice non utilizzati.

Prendi una funzione

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

Puoi provare che actnumbernon sarà mai 2così che Action2()non si chiama mai ...?

Non sono d'accordo sul problema dell'arresto. Non definirei tale codice morto anche se in realtà non verrà mai raggiunto.

Invece, consideriamo:

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

(Ignora gli errori di tipo e overflow) Codice morto?

Guarda questo esempio:

public boolean isEven(int i){

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

Il compilatore non può sapere che un int può essere solo pari o dispari. Pertanto, il compilatore deve essere in grado di comprendere la semantica del codice. Come dovrebbe essere implementato? Il compilatore non può garantire che il rendimento più basso non verrà mai eseguito. Pertanto il compilatore non è in grado di rilevare il codice morto.