MISRA-C é um padrão de desen­volvi­mento de soft­ware em lin­guagem C desen­volvida pela mesma que dá seu nome, a Motor Indus­try Soft­ware Reli­a­bil­ity Asso­ci­a­tion. Este padrão tem foco em sis­temas embar­ca­dos auto­mo­tivos, mas suas práti­cas podem ser exten­di­das tam­bém para out­ras areas, como equipa­men­tos médi­cos e aeroe­s­pa­ci­ais.

Seu prin­ci­pal obje­tivo é pro­mover um con­junto de mel­hores práti­cas para o desen­volvi­mento de soft­ware seguro e portável em lin­guagem C. Foi ini­cial­mente pub­li­cado em 1998, e mel­ho­rado no decor­rer dos anos. A segunda e mais atual edição saiu em 2004, e foi enti­t­u­lada de “Guide­lines for the use of the C lan­guage in crit­i­cal sys­tems”, e desde então vem sendo uti­lizada por empre­sas de vários ramos que desen­volvem soft­ware embar­cado.

Infe­liz­mente o doc­u­mento não está disponível de forma gra­tuita, e quem quiser con­hecer a fundo a norma pre­cisa fazer um inves­ti­mento para adquiri-la. Mas bas­tam algu­mas pesquisas no Google para encon­trar bas­tante infor­mação rel­e­vante à respeito do assunto.

Padrões de desenvolvimento

Antes de falar do padrão, vamos comen­tar sobre as moti­vações para usá-lo.

A lin­guagem C é uma das lin­gua­gens mais poderosas e flexíveis que exis­tem. E é por isso que ela é extrema­mente pop­u­lar em sis­temas embar­ca­dos. Se bem uti­lizada, tem ótima per­for­mance, pode gerar um código bem pequeno e facilita bas­tante o acesso ao hard­ware. Mas o prob­lema esta exata­mente em como começamos a frase ante­rior: “Se bem utilizada…”.

A lin­guagem C nas mãos de pro­gra­madores inex­pe­ri­entes pode ser um prob­lema. Sua flex­i­bil­i­dade é uma faca de dois gumes, pois dá poderes extras ao desen­volve­dor, que talvez ainda não esteja preparado para usá-los.

E é por isso que os padrões de soft­ware exis­tem. Para nos aju­dar a usar esta fer­ra­menta de pro­gra­mação (no nosso caso a lin­guagem C) da forma mais cor­reta pos­sível, segundo a norma, através de deter­mi­nadas regras.

O padrão MISRA-C:2004

Voltando ao padrão, o MISRA-C:2004 con­tém 141 regras divi­di­das em 21 cat­e­go­rias. Destas 141 regras, 121 são man­datórias e 20 são recomen­dadas. E para o código ser “MISRA-C Com­pli­ance”, pre­cisa estar de acordo com todas as 141 regras, sem exceção.

Infe­liz­mente não temos espaço aqui para apre­sen­tar e dis­cu­tir cada uma das regras (e até seria bem cansativo fazer isso), então vamos ver algu­mas das mais impor­tantes (e con­tro­ver­sas) regras deste padrão.

Rule 1: All code shall con­form to ISO 9899 stan­dard C, with no exten­sions permitted.

Tradução: Todo código deve estar de acordo com o padrão ISO 9899, sem per­mis­são para o uso de extensões.

A primeira regra já é uma das mais polêmi­cas do padrão MISRA-C. O padrão ISO, tam­bém con­hecido como C99, não foi desen­volvido com foco em sis­temas embar­ca­dos, então como vamos ter um código para um sis­tema embar­cado auto­mo­tivo em con­formi­dade com o C99? Um soft­ware embar­cado nor­mal­mente requer algu­mas exten­sões para poder lidar dire­ta­mente com o hard­ware, como por exem­plo a palavra chave inter­rupt usada em alguns com­pi­ladores para definir uma rotina de trata­mento de inter­rupção. E isso pode ser um prob­lema para o padrão MISRA-C.

Neste caso, o padrão MISRA-C per­mite alguns desvios à regra para exten­sões à lin­guagem. Estas exten­sões devem estar bem doc­u­men­tadas e cen­tral­izadas, como por exem­plo, todos os aces­sos ao hard­ware em um único arquivo.

Rule 2.2: Source code shall only use /* … */ style comments.

Tradução: O código-fonte deve usar ape­nas comen­tários no estilo /* … */ 

Essa regra é mais para garan­tir um padrão de estilo de cod­i­fi­cação. Nada de usar os comen­tários de linha “//” her­da­dos do C++.

Rule 6.3: Type­defs that indi­cate size and signed­ness should be used in place of the basic types.

Tradução: Type­defs que indicam o tamanho e o sinal da var­iável devem ser usa­dos no lugar dos tipos básicos.

Esse padrão dev­e­ria ser seguido por todos que pre­ten­dem garan­tir a porta­bil­i­dade do código entre difer­entes arquite­turas de hard­ware. Por exem­plo, o código abaixo tem o obje­tivo de setar o bit 17 da vari­avel reg, considerando-se que int é um inteiro é de 4 bytes.

1
2
3

int reg;
 
reg |= 0x10000;

Quando por­ta­mos este código para uma arquite­tura de 16 bits, este código não vai fun­cionar, já que um inteiro terá ape­nas 2 bytes. Então o que o padrão sug­ere é o código abaixo:

1
2
3
4
5

typedef int int32;
 
int32 reg;
 
reg |= 0x10000;

Neste caso, quando por­ta­mos o código, basta mudar a declar­ação do type­def para o tipo cor­reto de um inteiro de 32 bits, por exemplo:

1

typedef long int32;

Rule 8.1: Func­tions shall have pro­to­type dec­la­ra­tions and the pro­to­type shall be vis­i­ble at both the func­tion def­i­n­i­tion and call.

Tradução: Funções devem ter seus pro­tóti­pos declar­a­dos e visíveis à sua definição e às suas chamadas.

Se a função é usada ape­nas no arquivo em que é declar­ada, o ideal é declarar seu pro­tótipo no ini­cio do arquivo. Se a função é usada em out­ros arquivos/módulos, o ideal é declarar seu pro­tótipo em um arquivo de header e incluí-lo em todos os mod­u­los onde a função é declar­ada e usada. 

Rule 9.1: All auto­matic vari­ables shall have been assigned a value before being used

Tradução: Todas as var­iáveis automáti­cas (locais) devem ter um valor atribuido antes de serem usadas.

Esta regra pode evi­tar muitos erros. Declarou uma var­iável local, inicialize-a. Declarou um buffer, use mem­set ou bzero para inicializá-lo. 

Rule 14.1: There shall be no unreach­able code.

Tradução: Não deve exi­s­tir código que nunca é executado.

A maio­ria dos com­pi­ladores hoje, quando con­fig­u­rado para otimizar por tamanho, acaba removendo do binário códi­gos que nunca são exe­cu­ta­dos. Mas até para mel­ho­rar a leitura, é sem­pre bom fazer uma limpeza em códi­gos que nunca são exe­cu­ta­dos, como o else do código abaixo:

1
2
3
4
5
6
7

void initBuffer(char *buffer, unsigned int size)
{
    if (size >= 0)
        bzero(buffer, size);
    else
        logError("Tamanho invalido!");
}

A função logEr­ror() nunca será exe­cu­tada já que size é uma var­iável sem sinal, por­tanto nunca será menor que zero.

Rule 16.2: Func­tions shall not call them­selves, either directly or indirectly

Tradução: Funções não podem chamar elas mes­mas direta ou indiretamente.

Você quer ver as con­se­quên­cias de um stack over­flow? Use funções recur­si­vas! Recursão pode ser às vezes uma solução ele­gante, mas con­some muitos recur­sos de memória e proces­sa­mento. Evite e busque soluções alternativas.

Rule 16.10: If a func­tion returns error infor­ma­tion, then that error infor­ma­tion shall be tested.

Tradução: Se uma função retorna infor­mações de erro, este erro deve ser checado.

Esta regra deve ser sem­pre seguida. Já vi muito código por aí chamando mal­loc() mas não ver­i­f­i­cando o resul­tado. Depois per­dem horas para debugar o código.

Rule 20.4: Dynamic heap mem­ory allo­ca­tion shall not be used

Tradução: Alo­cação dinâmica de memória não deve ser usada.

OK, na minha opinião esta é a regra mais polêmica do padrão. Alo­cação dinâmica de memória pode ser a causa da maio­ria (e dos piores) bugs da sua apli­cação. Frag­men­tação de memória e mem­ory leak são os prin­ci­pais cul­pa­dos. Mas às vezes pre­cisamos do mal­loc() para resolver alguns prob­le­mas. Minha sug­estão: use com muito cuidado e ape­nas como último recurso.

Rule 49: Tests of a value against zero should be made explicit, unless the operand is effec­tively Boolean.

Tradução: Ver­i­ficar se uma var­iável está zer­ada deve ser feito de forma explicita, a não ser que o operando seja booleano.

Bom, logo de cara vou dizer que entendo os motivos, mas dis­cordo desta regra. O que vocês acham mais legível, o primeiro if (padrão MISRA-C) ou o segundo?

1
2
3
4
5
6
7

if (bufferVazio == 0) { /* padrao MISRA-C */
    return;
}
 
if (!bufferVazio) {
    return;
}

Rule 104: Non-constant point­ers to func­tions shall not be used.

Tradução: Pon­teiros não con­stantes para funções não devem ser usados.

Dis­cordo nova­mente! Em alguns casos, pon­teiros para funções podem ser uma solução bem ele­gante, prática e sem muitos cus­tos para o sis­tema. Por exem­plo, dá para se imple­men­tar uma rotina de trata­mento de uma máquina de esta­dos com 3 ou 4 lin­has de código usando pon­teiro para funções (o meu artigo sobre máquina de esta­dos fala sobre isso). 

Para finalizar, exis­tem muitas fer­ra­men­tas de análise estática de código que podem ser usadas para ver­i­ficar se um código é com­patível com o padrão MISRA-C como PC-LINT, CodeCheck e QA-C.

Ter um código com­patível com o padrão não sig­nifica ape­nas que você vai desen­volver um código mais seguro e portável. Sig­nifica tam­bém que você vai estar mudando sua forma de pro­gra­mar, nem sem­pre para mel­hor. Inter­prete, cri­tique e veja o que é mel­hor para a solução que esta bus­cando. Você não pre­cisa seguir à risca todas as regras, ape­nas aque­las que se apli­cam à seu pro­jeto. E pode não estar 100% com­pa­tivel com o padrão, mas vai com certeza ter mel­ho­rado a qual­i­dade do seu código. De qual­quer forma, vale a pena pelo menos dar uma olhada. O único risco que você vai cor­rer é apren­der um pouco mais com isso.

Um abraço,

Ser­gio Prado

Sem posts relacionados.