Compiler erkennt offensichtlich nicht initialisierte Variable nicht

Alle C-Compiler, die ich ausprobiert habe, erkennen im folgenden Code-Snippet keine nicht initialisierten Variablen. Doch der Fall liegt hier auf der Hand.

Kümmern Sie sich nicht um die Funktionalität dieses Snippets. Es ist kein echter Code, und ich habe ihn für die Untersuchung dieses Problems entfernt.

BOOL NearEqual (int tauxprecis, int max, int value)
{
  int tauxtrouve;      // Not initialized at this point
  int totaldiff;       // Not initialized at this point

  for (int i = 0; i < max; i++)
  {
    if (2 < totaldiff)  // At this point totaldiff is not initialized
    {
      totaldiff = 2;
      tauxtrouve = value;  // Commenting this line out will produce warning
    }
  }

  return tauxtrouve == tauxprecis ;  // At this point tauxtrouve is potentially
                                     // not initialized.
}

Andererseits, wenn ich auskommentiere tauxtrouve = value ;Ich bekomme die "local variable 'tauxtrouve' used without having been initialized" Warnung.

Ich habe diese Compiler ausprobiert:

• GCC 4.9.2 mit -Wall -WExtra
• Microsoft Visual C++ 2013 mit allen aktivierten Warnungen

Die Offensichtlichkeit, mit der diese Variable nicht initialisiert wird, ist übertrieben. Die Pfadanalyse kostet Zeit und Ihre Compiler-Anbieter wollten das Feature entweder nicht implementieren oder dachten, es würde Sie zu viel Zeit kosten – oder Sie haben sich einfach nicht explizit dafür entschieden.

Zum Beispiel mit clang:

$ clang -Wall -Wextra -c obvious.c 
$ clang -Wall -Wextra --analyze -c obvious.c 
obvious.c:9:11: warning: The right operand of '<' is a garbage value
    if (2 < totaldiff)  // at this point totaldiff is not initialized
          ^ ~~~~~~~~~
obvious.c:16:21: warning: The left operand of '==' is a garbage value
  return tauxtrouve == tauxprecis ;  // at this point tauxtrouve is potentially
         ~~~~~~~~~~ ^
2 warnings generated.

Der Unterschied in der Ausführungszeit für diese naiven Beispiele ist vernachlässigbar. Aber stellen Sie sich eine Übersetzungseinheit mit Tausenden von Zeilen, Dutzenden von Funktionen vor, jede mit Schleifen und starker Verschachtelung. Die Anzahl der Pfade summiert sich schnell und wird zu einer großen Bürde, um zu analysieren, ob die erste Iteration durch die Schleife vor diesem Vergleich erfolgt, ob die Zuweisung erfolgt oder nicht.

BEARBEITEN: @Matthieu weist darauf hin, dass bei LLVM/clang die Pfadanalyse, die erforderlich ist, um die Verwendung des nicht initialisierten Werts zu finden, nicht zusammengesetzt wird, wenn die Verschachtelung aufgrund der vom IR verwendeten SSA-Notation zunimmt.

Es war nicht so einfach wie “-S -emit-llvm” wie ich gehofft hatte, aber ich fand die von ihm beschriebene Ausgabe in SSA-Notation. Ich bin ehrlich, ich bin mit LLVM IR nicht vertraut genug, um sicher zu sein, aber ich nehme Matthieus Wort dafür.

Fazit: verwenden clang mit --analyzeoder überzeugen Sie jemanden, das Problem zu beheben gcc Insekt.

; Function Attrs: nounwind uwtable
define i32 @NearEqual(i32 %tauxprecis, i32 %max, i32 %value) #0 {
  br label %1

; <label>:1                                       ; preds = %7, %0
  %tauxtrouve.0 = phi i32 [ undef, %0 ], [ %tauxtrouve.1, %7 ]
  %i.0 = phi i32 [ 0, %0 ], [ %8, %7 ]
  %2 = icmp slt i32 %i.0, %max
  br i1 %2, label %3, label %9

; <label>:3                                       ; preds = %1
  %4 = icmp slt i32 2, 2
  br i1 %4, label %5, label %6

; <label>:5                                       ; preds = %3
  br label %6

; <label>:6                                       ; preds = %5, %3
  %tauxtrouve.1 = phi i32 [ %value, %5 ], [ %tauxtrouve.0, %3 ]
  br label %7

; <label>:7                                       ; preds = %6
  %8 = add nsw i32 %i.0, 1
  br label %1

; <label>:9                                       ; preds = %1
  %10 = icmp eq i32 %tauxtrouve.0, %tauxprecis
  %11 = zext i1 %10 to i32
  ret i32 %11
}

Ja, es sollte eine Warnung über diese nicht initialisierte Variable auslösen, aber es ist so ein GCC-Bug. Das dort angegebene Beispiel lautet:

unsigned bmp_iter_set ();
int something (void);

void bitmap_print_value_set (void)
{
    unsigned first;

    for (; bmp_iter_set (); )
    {
        if (!first)
            something ();
        first = 0;
    }
}

Und diagnostiziert -O2 -W -Wall.

Leider ist dieses Jahr das 10-jährige Jubiläum dieses Fehlers!

Diese Antwort richtet sich nur an GCC.

Nach weiteren Nachforschungen und Kommentaren ist mehr los als in meiner vorherigen Antwort. Dieses Code-Snippet enthält zwei nicht initialisierte Variablen, von denen jede aus einem anderen Grund nicht erkannt wird.

Zunächst einmal die GCC-Dokumentation für die -Wuninitialized Möglichkeit sagt:

Da diese Warnungen von der Optimierung abhängen, hängen die genauen Variablen oder Elemente, für die es Warnungen gibt, von den genauen Optimierungsoptionen und der verwendeten GCC-Version ab.

Frühere Versionen des GCC-Handbuchs haben dies expliziter formuliert. Hier ein Auszug aus der Handbuch für GCC 3.3.6:

Diese Warnungen sind nur bei der Optimierung der Kompilierung möglich, da sie Datenflussinformationen erfordern, die nur bei der Optimierung berechnet werden. Wenn Sie -O nicht angeben, erhalten Sie diese Warnungen einfach nicht.

Es scheint, dass die aktuelle Version ohne nicht initialisierte Variablen einige Warnungen ausgeben kann -Oaber Sie erzielen damit immer noch viel bessere Ergebnisse.

Wenn ich Ihr Beispiel mit kompiliere gcc -std=c99 -Wall -OIch bekomme:

foo.c: In function ‘NearEqual’:
foo.c:15:21: warning: ‘tauxtrouve’ is used uninitialized in this function [-Wuninitialized]
   return tauxtrouve == tauxprecis ;  // at this point tauxtrouve is potentially
                     ^

(Beachten Sie, dass dies mit GCC 4.8.2 gilt, da ich 4.9.x nicht installiert habe, aber das Prinzip sollte dasselbe sein.)

Das erkennt also die Tatsache, dass tauxtrouve ist nicht initialisiert.

Wenn wir den Code jedoch teilweise reparieren, indem wir einen Initialisierer für hinzufügen tauxtrouve (aber nicht für totaldiff), dann gcc -std=c99 -Wall -O akzeptiert es ohne Vorwarnung. Dies scheint ein Beispiel für den in der Antwort von Hackks zitierten “Fehler” zu sein.

Es stellt sich die Frage, ob dies wirklich als Fehler angesehen werden sollte: GCC verspricht nicht, jede mögliche Instanz einer nicht initialisierten Variablen abzufangen. In der Tat kann es dies nicht mit perfekter Genauigkeit tun, denn das ist die Halteproblem. Warnungen wie diese können also hilfreich sein, wenn sie funktionieren, aber das Fehlen von Warnungen beweist nicht, dass Ihr Code frei von nicht initialisierten Variablen ist! Sie sind wirklich kein Ersatz für die sorgfältige Überprüfung des eigenen Codes.

In dem durch Hacks verlinkter Fehlerberichtgibt es viele Diskussionen darüber, ob der Fehler überhaupt behebbar ist oder ob der Versuch, dieses bestimmte Konstrukt zu erkennen, zu einer inakzeptablen Falsch-Positiv-Rate für anderen korrekten Code führen würde.

Michael, ich weiß nicht, auf welcher Version von Visual Studio 2013 Sie das ausprobiert haben, aber es ist mit Sicherheit veraltet. Visual Studio 2013-Update 4 korrekt erzeugt die folgende Fehlermeldung bei der ersten Verwendung von totaldiff:

error C4700: uninitialized local variable 'totaldiff' used

Sie sollten erwägen, Ihre Arbeitsumgebung zu aktualisieren.

Übrigens, hier ist, was ich direkt im Editor sehe: