Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 6 minutes
Misra is een van de populairste richtlijnen voor C-code om bugs te vermijden. Na acht jaar kwam half maart de nieuwe versie uit, onder meer met ondersteuning voor C:99. Misra-specialist Paul Burden van Programming Research legt uit wat de standaard precies behelst en wat er allemaal is veranderd in de 2012-versie.
Eenieder die C-code klopt voor missiekritieke embedded systemen heeft een goede kans dat hij zich moet houden aan de Misra-standaarden: een set restricties waarmee het iets moeilijker wordt om veelgemaakte fouten ook daadwerkelijk te begaan. Oorspronkelijk werd de standaard opgesteld door een groep Britse leveranciers in de automotivesector, maar ondertussen zijn de richtlijnen tot ver buiten deze markt verspreid. Uit een recente inventarisatie van VDC Research bleek dat de helft van de bedrijven die een codeerrichtlijn gebruiken hun eigen standaard ontwikkelen, maar daarna is Misra-C veruit het populairst met een aandeel van bijna achttien procent. Bovendien zijn de interne richtlijnen vaak ook weer op Misra-C gebaseerd.
De Misra-richtlijnen werden oorspronkelijk in 1998 gepubliceerd en in 2004 aangepast aan de voortschrijdende inzichten. Dat gebeurt nu opnieuw: op 18 maart is de Misra-C:2012-richtlijn gepubliceerd. Bits&Chips sprak met Paul Burden van Programming Research, dat onder meer tools ontwikkelt om broncode op het naleven van Misra en andere codeerstandaarden te controleren. Als lid van het standaardisatiecommité was Burden betrokken bij de ontwikkeling van de nieuwe versie.
Wat doet de Misra-standaard eigenlijk precies?
’Misra is een set regels om op een defensieve manier code te schrijven, zodat de kans kleiner wordt dat je bugs introduceert – het soort bugs dat je niet met een tool kunt vinden. De standaard voorkomt dat je code produceert die weliswaar valide is in C, maar waarschijnlijk wel fout.‘
Kunt u een voorbeeld geven?
’Er is een simpele regel die betrekking heeft op het for-statement. Als je na de drie controle-expressies per ongeluk een puntkomma schrijft, is dat compleet valide in C, want een puntkomma is een statement op zichzelf – het null-statement dat niks doet. Maar het is in potentie een bug, zelfs zeer waarschijnlijk een bug. Dus een van de Misra-regels is dat er op een for-statement altijd een samengesteld statement tussen accolades moet volgen. Dat voorkomt ook dat je een enkel ingesprongen statement als blok kunt gebruiken. Daarmee kun je de mist in gaan als je een extra statement wilt toevoegen aan je loop-body.‘
’Codeerregels beperken je ook in de operaties die een grote kans hebben om fout te zijn. Het is in C bijvoorbeeld toegestaan om een negatieve waarde toe te kennen aan een unsigned variabele, maar dat is niet verstandig om te doen.‘
Het zijn dus allemaal regels die makkelijk met een tool te controleren zijn?
’De meeste wel. Een codeerstandaard heeft alleen zin als je kunt controleren of die wordt nageleefd. Maar er is een onderscheid tussen wat we noemen rules en directives. De meeste codeervoorschriften zijn eigenschappen van de broncode, dat zijn harde rules. Van alle 143 van deze regels in de nieuwe 2012-standaard kan een tool zeggen of ze worden nageleefd door simpelweg naar de broncode te kijken. Er zijn echter ook voorschriften waarover een tool niet simpel een beslissing kan nemen. Misra-C verbiedt het bijvoorbeeld om een stuk code te inactiveren met commentaarsymbolen. Een probleem met een dergelijke regel is dat een tool daarvoor het commentaar moet analyseren en beslissen of dat C-code is of niet. Voor ons is dat eenvoudig, maar voor de tool is dat erg lastig. Die geeft bij zo‘n voorschrift een subjectief oordeel in plaats van een zwart-witbeslissing. Daarom noemen we dat een directive. In Misra-C:2012 zijn er zestien van dergelijke richtlijnen.‘
Waarom is er nu een nieuwe versie?
’Er zijn twee belangrijke redenen. Een: we zagen ruimte voor verbetering, en twee: Misra-C:2012 brengt ons met slechts dertien jaar vertraging in het nieuwe, moderne tijdperk van C:99.‘
’Er zijn ondertussen drie versies van C gepubliceerd: de oorspronkelijke in 1990, de geüpdatete in 1999 en nog een versie in 2011. Tot nu toe specificeerde Misra altijd dat je C:90 moest gebruiken. De latere versies introduceren nieuwe features en daarmee nieuwe gevaren, terwijl Misra-C draait om veiligheid en betrouwbaarheid van je code. Misra-C:2012 geeft nieuwe regels om om te gaan met de nieuwe mogelijkheden van C:99.‘
’Naast de ondersteuning voor C:99 zijn er allerlei verbeteringen in de bestaande regels. Sommige regels waren niet zo goed gedefinieerd en waren voor verschillende uitleg vatbaar. Regels kregen wel eens een slechte reputatie omdat ze in de praktijk nogal onhandig waren en té beschermend.‘
Kunt u daar ook een voorbeeld van geven?
’Laten we even teruggaan naar het null-statement. De vorige versie van Misra-C legde allerlei regels op rond het gebruik daarvan. Bijvoorbeeld: het mag alleen voorkomen op een eigen regel, tenzij de rest van de regel commentaar is, maar dan moet er een spatie tussen zitten. Dat was een gecompliceerde, vervelende regel. En achteraf gezien totaal overbodig: null-statements zijn nooit een probleem, tenzij ze de body van een controlestatement vormen zoals in het for-voorbeeld. Een losse puntkomma tussen twee assignment-statements is evenmin een probleem – niet netjes, maar geen probleem. Dus alle pogingen om te reguleren hoe je een null-statement toevoegt is tijdverspilling. Het enige dat je moet doen, is ervoor zorgen dat de body‘s van je controlestatements samengesteld zijn.‘
’Impliciete typeconversies zijn ook een belangrijk aandachtspunt. C laat vrij veel toe op dat gebied, dat is een zwak punt van de taal. Het wordt bijvoorbeeld op geen enkele manier verboden om een signed en een unsigned getal met elkaar te vermenigvuldigen, een bewerking die nuttig kan zijn of complete onzin produceert afhankelijk van de types die je gebruikt. Misra-C bevat een flink pak regels om te reguleren welke bewerkingen en welke typeconversies toegestaan zijn. Dat is behoorlijk uitgebreid in de nieuwe versie.‘
Zijn er naast de regels en de ondersteunde C-versie nog andere dingen veranderd?
’In Misra-C:2004 waren voorschriften eigenlijk nooit volledig verplicht, dat wordt nu voor sommige gevallen aangepast. In de oude situatie had je twee classificaties: advisory en required. Bij de eerste wordt geadviseerd om het zus en zo te doen, maar de beslissing is uiteindelijk aan de gebruiker. De tweede moet je in principe wel opvolgen, maar daar kun je per geval of projectbreed van afwijken. Daar moet wel een goede reden voor zijn en die moet beargumenteerd en gedocumenteerd worden, maar het is mogelijk.‘
’Er is misschien een dozijn regels die zo zwart-wit zijn, zo oncontroversieel, dat we geen enkele mogelijke reden zien om daar ooit van af te wijken. Een uitzondering is simpelweg nooit logisch of zinvol. In Misra-C:2012 hebben we daarom mandatory als derde categorie toegevoegd.‘
’Een andere toevoeging betreft de beslisbaarheid. Zaken als de impliciete conversie van een signed naar een unsigned getal gaan om een enkel statement in de broncode en zijn voor een tool simpel te controleren. Voor andere voorschriften moet de tool veel meer broncode analyseren. Als er een systeembrede analyse moet worden uitgevoerd, kan het mogelijk zijn dat het niet meer te garanderen is dat de regel in alle gevallen wordt nageleefd. In Misra-C:2012 kun je daarom stellen dat een regel onbeslisbaar is.‘
Wat heb je daar precies aan?
’Ik denk dat het wat eerlijkheid toevoegt aan de analyse. Het is dan wel een vereiste, maar helaas kun je er niet zeker van zijn dat je eraan voldoet. Er zijn veel tools die claimen Misra te ondersteunen, maar in werkelijkheid is het dus geen zwart-witbewering. Codeerrichtlijnen zijn in het verleden vaak over dit onderscheid heen gestapt. Mensen konden een vinkje zetten omdat de tool zei dat het klopte, maar in werkelijkheid kun je niet weten of alle overtredingen gevonden zijn.‘
