Compiler-Warnungen sind gut. Weniger als \u201e-Wall\u201c zu verwenden sollte in den wirklich tollen Unternehmen(tm) ein K\u00fcndigungsgrund sein. So viel zur Theorie, aber was wird mit den endlosen Listen von Warnungen gemacht? Meistens nichts. Der Code l\u00e4uft und ist in seltenen F\u00e4llen vielleicht sogar gut entworfen, warum also m\u00e4kligen Compilern nachputzen? Ein kleines Beispiel aus meinem aktuellen Projekt.<\/p>\n
Zu implementieren ist der Bytecode-Handler f\u00fcr \u201eanewarray\u201c in einer Java VM (selbstverst\u00e4ndlich in C geschrieben). Wie der Spezifikation des Bytecodes<\/a> entnommen werden kann, muss dabei unter anderem eine Variable \u201ecount\u201c vom Stack genommen werden. Sie stellt eine vorzeichenbehaftete Zwei-Byte-Ganzzahl dar. Wenn sie kleiner als Null ist, soll eine Exception ausgel\u00f6st werden. Dieser Spezifikation bin ich selbstverst\u00e4ndlich gefolgt und habe auch die \u00dcberpr\u00fcfung f\u00fcr die Exception eingebaut. Leider habe ich \u201ecount\u201c vom Stack genommen und in einer nicht-vorzeichenbehafteten Variablen gespeichert, so dass negative Zahlen zu sehr gro\u00dfen positiven wurden. gcc hat mich freundlicherweise daraufhingewiesen, in dem er zu \u201eif (count < 0)\u201c die hilfreiche Warnung \u201ecomparison is always false due to limited range of data type\u201c ausgab. Das war zwar weder ein weltbewegender Bug noch w\u00e4re er besonders schwer zu entdecken, wenn er denn wirklich mal auftreten sollte, aber es war eben doch ein Bug, und gcc hat mich beim ersten Kompilieren darauf hingewiesen.\n\nLeider haben Compiler-Warnungen die Angewohnheit, in Horden aufzutreten, das Terminal zu \u00fcberfluten und nicht lockerzulassen, bis \u201e-Wall\u201c wieder aus dem Makefile verschwindet. Im obengenannten Projekt geh\u00f6ren viele Warnungen der unused-parameter-Spezies an und stehen damit im Zusammenhang, dass manche Funktionen je nach Ziel-Platform nicht implementiert sind, also leer. Deren Parameter werden dann selbstverst\u00e4ndlich nicht verwendet, aber das ist auch richtig so: Wenn das Board keine LEDs hat, kann ich wenig mit dem Parameter anfangen, der angibt, welche LEDs leuchten sollen. Um diese false positives abzufangen, gibt es bei C++ einen sch\u00f6nen Trick: Der Name des Parameters wird einfach weggelassen<\/a>. Das produziert in C einen ausgewachsenen Compiler-Fehler, aber daf\u00fcr unterst\u00fctzt gcc das Attribut \u201e__attribute__((unused))<\/a>\u201c, mit dem Parameter und andere Variablen als \u201ewird m\u00f6glicherweise nicht verwendet\u201c markiert werden k\u00f6nnen. Ein Pr\u00e4prozessor-Makro, gefunden bei Martin Pool<\/a>, verpackt das ganze sch\u00f6n: Splint kennt ein \u00e4hnliches Attribut, das hier auch gleich verwendet wird. Ebenso gut funktioniert es, den Parameter scheinbar zu verwenden, bsw. mit einem \u201e(void) param;\u201c am Anfang der Methode.<\/p>\n Um Code \u00fcberhaupt erstmal lesbar zu machen, ist \u00fcbrigens Artistic Style sehr n\u00fctzlich, und wem gcc noch nicht genug Warnungen auswirft, der mag Interesse an Splint haben. Beide Werkzeuge sind in Debian als Package erh\u00e4ltlich. Damit ist die statische Code-Analyse aber auch weitgehend ausgesch\u00f6pft.<\/p>\n","protected":false},"excerpt":{"rendered":" Compiler-Warnungen sind gut. Weniger als \u201e-Wall\u201c zu verwenden sollte in den wirklich tollen Unternehmen(tm) ein K\u00fcndigungsgrund sein. So viel zur Theorie, aber was wird mit den endlosen Listen von Warnungen gemacht? Meistens nichts. Der Code l\u00e4uft und ist in seltenen F\u00e4llen vielleicht sogar gut entworfen, warum also m\u00e4kligen Compilern nachputzen? Ein kleines Beispiel aus meinem … <\/p>\n
\n
\n#if defined(__GNUC__)
\n# define UNUSED(x) UNUSED_ ## x __attribute__((unused))
\n#elif defined(S_SPLINT_S)
\n# define UNUSED(x) \/*@unused@*\/ x
\n#else
\n# define UNUSED(x) x
\n#endif
\n<\/code><\/p>\n