Eine saubere Sache

ANSI

Dass LCLint tatsächlich noch tiefgründigere Sachen kann, zeigt das folgende Listing 3 (reihenfolge.c):

01 extern int glob;
02
03 extern int aenderglob(void)
04  /*@globals glob@*/
05  /*@modifies glob@*/;
06
07 int main(void)
08 {
09   int i=1;
10   int x;
11
12   x = i++ * i;
13   i+=aenderglob() * glob;
14
15   return 1;
16 }

Bei der Prüfung mit LCLint bekommt man folgendes Ergebnis:

$ lclint reihenfolge.c
reihenfolge.c: (in function main)
reihenfolge.c:12,13: Expression has undefined behavior (value of right operand
                        modified by left operand): i++ * i
  Code has unspecified behavior. Order of evaluation of function parameters or
  subexpressions is not defined, so if a value is used and modified in
  different places not separated by a sequence point constraining evaluation
  order, then the result of the expression is unspecified. (-evalorder will
  suppress message)
reihenfolge.c:13,21: Expression has undefined behavior (value of right operand
                        modified by left operand): aenderglob() * glob

• Was mit der Berechnung von x++ * x gemeint sein könnte, ist im ersten Augenblick nicht ganz klar. Es könnte bedeuten, dass zuerst x * x gebildet, dann dem Ergebnis zugewiesen, und erst anschließend die Variable x inkrementiert wird. Andererseits könnte es bedeuten, dass erst Variable x genommen, dann inkrementiert, und dann mit dem inkrementierten x multipliziert wird. Eingefleischte C-Profis mögen wissen, was ihr Compiler daraus macht, es ist allerdings nicht nur schlechter Stil, C-Programme auf diese Art und Weise zu schreiben, es verstößt überdies gegen ANSI C; dort ist vereinbahrt, dass alle Seiteneffekte in einer Sequenz bereits beendet sein müssen, bevor dieser Punkt erreicht wird, und keine Seiteneffekte auftreten dürfen, bevor er beendet ist.
• Interessant ist auch die zweite Meldung von LCLint, die darauf hinweist, dass die Variable glob innerhalb der Funktion aenderglob() geändert wird und damit hier die Reihenfolge der Verarbeitungsschritte nicht definiert ist. Dies konnte LCLint entdecken, obwohl die Funktion aenderglob() selbst eine externe Funktion ist – zu diesem Zweck wurde der stilisierte Kommentar /*@modifies glob@*/ in das Listing eingefügt.

Der Herr der endlosen Ringe

LCLint kann ganz gut Endlosschleifen erkennen. Dazu betrachten wir folgendes kleines Beispiel (Listing 4, endlos.c):

01 extern int f(void)
02   /*@modifies nothing@*/;
03
04 int main(void)
05 {
06   int i=1;
07
08   while(0 < f()) i++;
09
10   return 1;
11 }

LCLint gibt dann aus:

endlos.c: (in function main)
endlos.c:8,9: Suspected infinite loop.  No value used in loop test ([result of
                 f]) is modified by test or loop body.
  This appears to be an infinite loop. Nothing in the body of the loop or the
  loop test modifies the value of the loop test. Perhaps the specification of a
  function called in the loop body is missing a modification. (-infloops will
  suppress message)

LCLint erkennt am stilisierten Kommentar /*@modifies nothing@*/, dass die Funktion keine Variable ändert, und nimmt daher an, dass der Rückgabewert für die Funktion konstant ist. Das riecht förmlich nach einer Endlosschleife, und LCLint erkennt diese.

Das Programm LCLint ist unter http://lclint.cs.virginia.edu/ zu finden. Dort gibt es eine ausführliche Dokumentation. Das zugehörige RPM-Paket gehört zum Umfang der meisten Distributionen (meine SuSE hat es jedenfalls). Insbesondere gilt für den LCLint: Probieren, probieren und weiter probieren.

Wer LCLint richtig anwendet, der findet bereits im Vorfeld viele Fehler. Ich jedenfalls habe meiner Firma unlängst vorgeschlagen, die C-Programme, die wir von außerhalb einkaufen, vorher durch LCLint qualitätszusichern. Und das beweist schon, dass sich LCLint nicht nur für den kleinen Mann, sondern auch für die ganz großen Firmen eignet…