Compiler vertelt weinig over programmeerfouten

24 juni 2010

Het is goed gebruik om compilers op het hoogste waarschuwingsniveau in te stellen tijdens de ontwikkeling van software. Overtredingen van taalstandaarden, gevaarlijke constructies en hindernissen bij porten komen zo snel boven water. Toch ontdekken compilers maar een fractie van de fouten, blijkt uit een case study waarbij de meldingen van vier populaire compilers werden vergeleken met de output van een statische-codeanalysetool.

Als broncode zonder foutmeldingen of waarschuwingen compileert, wordt de software vaak als ‘klaar’ beschouwd en gaat die verder naar de tests of code-review in de verificatiefase. Compilers controleren echter alleen op de syntax van de software. Het scala van compilerwaarschuwingen is daarmee ernstig beperkt vergeleken met een statische-analyse- (SA) of coding standards enforcing-tool (CSE).

In dit artikel voeren we een case study uit waarin we een aantal populaire C++-compilers vergelijken met onze eigen tool voor statische analyse en CSE. We testen de compilers op Gnu Common C++ 2 versie 1.6.3, een bibliotheek van ongeveer 42 duizend regels code. Aangezien het om cross-platformcode gaat, is er geen voorkeur voor een bepaalde compiler en beschouwen we het als een representatieve steekproef. De bescheiden omvang maakt het mogelijk om handmatig alle compilerwaarschuwingen te controleren op nauwkeurigheid en zorgt ervoor dat hun diversiteit en aantal niet triviaal is.

We hebben vier compilers onderzocht: GCC, Visual C++, C++ Builder en Intels C++ Compiler. De Team Edition vult de standaard compilerwaarschuwingen van Visual C++ aan met een code-analyse-feature. De output hiervan hebben we apart meegenomen. Van elke compiler hebben we de nieuwste versie met het hoogst mogelijke waarschuwingsniveau gebruikt.

De Misra C++- standaard dicteert dat een variabele in de kleinst mogelijke scope wordt gedefinieerd. Compilers zijn doorgaans niet sterk in het naleven van dit soort standaarden.

Statische-analysetools kunnen legale maar gevaarlijke code opsporen, zoals pointerconversies die een portabiliteitsprobleem vormen.

We denken dat de gekozen compilers een representatieve keuze vormen en dat de resultaten naar andere gebieden zijn door te trekken. De Intel-compiler gebruikt het EDG-front-end, waar ook de meeste embedded compilers op zijn gebaseerd. GCC is sterk in opkomst in combinatie met embedded Linux. Er zijn inmiddels ook leveranciers zoals Wind River die compilers leveren met een front-end van GCC.

Van de statische-analysetool QA C++ hebben we versie 2.5 gebruikt. Dit is zelf geen compiler en genereert dus geen objectcode, maar analyseert de broncode op mogelijke fouten en conformiteit aan codeerstandaarden. Hiervoor is het gereedschap voorzien van een Iso C++-conforme front-end.

Agenda

Aangezien deze compilers op verschillende front-ends gebaseerd zijn, kunnen we verschillende waarschuwingen van elk verwachten. Tabel 1 toont voor de verschillende categorieën het percentage van de statische-analysemeldingen die ook door de compilers worden gevonden. De kopregel toont de gebruikte compilerversies en -opties. Ook de omgekeerde weg is weergegeven: welk percentage van de compilerwaarschuwingen ook door de statische-analysetool worden gevonden.

Zelfs met het hoogste waarschuwingsniveau aan blijft het aantal meldingen van de compilers achter bij de rapportage via statische analyse (SA).

De SA-tool vindt in totaal 412 verschillende meldingen, aanzienlijk meer dan de geteste compilers. Van de compilers komt Visual C++ met Code Analyse (de /analyze-optie) als beste uit de bus met zestien waarschuwingen. Overigens is het interessant om te zien dat Visual C++ zonder deze optie juist de minste waarschuwingen produceert.

Gemiddeld vindt de SA-tool 84 procent van de waarschuwingen die de compilers genereren. Deze kant van de vergelijking wordt slechts gegeven voor de volledigheid, aangezien ontwikkelaars worden geacht om compilerwaarschuwingen aan te zetten onafhankelijk of er statische analyse wordt uitgevoerd.

Uit Tabel 1 blijkt dat de compilers de categorie ‘Efficiëntie en C++-gebruik’ mijden met hun waarschuwingen. Dit is te verwachten, aangezien de compileroptimalisaties in de back-end worden uitgevoerd, typisch zonder melding. Hierbij moet worden opgemerkt dat SA-tools met hun checks doorgaans een breder gebied bestrijken dan wat compilers optimaliseren.

Portabiliteit is een andere waarschuwingscategorie die ontbreekt in het arsenaal van de compilers. Alleen C++ Builder produceert een enkele waarschuwing die als portabiliteitsmelding kan worden geclassificeerd, tegenover zeventien van de statische-analysetool. Deze waarschuwingen vertegenwoordigen constructies die weliswaar voldoen aan de Iso C++-taaldefinitie, maar in verschillende compilerimplementaties anders kunnen worden opgevat en zo problemen kunnen veroorzaken. Het is niet ongewoon voor compilerleveranciers om ontwikkelaars in te sluiten door uitbreidingen op Iso C++ aan te bieden en het is dan ook niet verrassend dat portabiliteit niet hoog op hun agenda staat.

Hiermee komen we op het onderdeel ‘Iso C++-naleving’, waarvoor de statische-analysetool een afzonderlijke categorie van waarschuwingen biedt. Voor de meeste compilerleveranciers komt Iso-C++-conformiteit neer op het accepteren van zoveel mogelijk geldige C++-code, terwijl het detecteren van niet-conforme code – vaak hun eigen taaluitbreidingen – wordt vermeden. Bij een CSE-tool is het detecteren van Iso C++-overtredingen juist een van de sterke punten, blijkt uit Tabel 1.

De meeste compilerwaarschuwingen kunnen worden geclassificeerd als ontwerp- en onderhoudsproblemen. Zelfs voor zulke fouten is de afdekking echter laag in vergelijking met de statische-analysetool. Visual C++-plus-codeanalyse scoort met 7 procent overlap als beste. Het mag duidelijk zijn dat compilers de kans om codeherbruikbaarheid te verbeteren vrijwel onaangeroerd laten.

Ongewenst gedrag

Andere soorten waarschuwingen die compilers doorgaans vermijden zijn naamgevingsconventies, broncode-indentatie en -lay-out, grenzen aan complexiteitsmetrieken en het verbieden van bepaalde symbolen (bijvoorbeeld throw) of functies (bijvoorbeeld malloc()). De opmerkelijke uitzondering voor dat laatste is Visual C++ met codeanalyse, dat vast ingebouwde waarschuwingen heeft voor gebruik van de functies _alloca(), _snprintf() en TerminateThread(). Omdat dit niet zo ver gaat als de configureerbare waarschuwingen van de analysetool waarmee elke ongewenste functie verboden kan worden, hebben we hiervoor een halve punt toegekend. Deze compiler scoort daarmee 10 procent voor het controleren op lokale (bedrijfsspecifieke) standaarden.

Compilers zijn ontworpen om zo veel mogelijk code te accepteren en zijn daardoor niet erg goed in het naleven van codeerstandaarden.

Om de daadwerkelijke meldingen van elke tool te vergelijken hebben we enkele populaire C++-codeerstandaarden gebruikt als objectieve maat. Zoals te zien in Tabel 2 biedt geen van de compilers enige serieus te nemen controle voor High Integrity C++, JSF++ of Misra C++.

Het is een wijdverbreide misvatting dat compilerwaarschuwingen voldoende zijn om broncode statisch te analyseren. De beschikbare waarschuwingen van marktleidende compilers zijn beperkt vergeleken bij een specifieke statische-analyse- en CSE-tool. De beschikbare controles zijn vooral gericht op ongewenst gedrag van de code en onderhoudsproblemen. Herbruikbaarheid en portabiliteit worden nagenoeg over het hoofd gezien. In de praktijk kan elke gemiste melding van invloed zijn op de kwaliteit van de code, zowel rond onderhoudbaarheid, portabiliteit als om herbruikbaarheid. Dat kan de uitrol ervan flink in de weg zitten, ondanks dat het grootste deel van de broncode zonder melding door de compilerchecks komt.

Wojciech Basalaj heeft negen jaar technische ervaring in de consultancygroep en is de meest ervaren technisch adviseur van PRQA. Frank van den Beuken heeft acht jaar technische ervaring bij PRQA als technisch adviseur in de consultancygroep.

Wojciech Basalaj en Frank van den Beuken

Terug naar overzicht