MISRA-C è applicabile alle applicazioni Linux

Question

Comprendo che gli standard MISRA-C sono destinati al firmware incorporato. Quando Linux incorporato è la tua piattaforma di prodotto, è possibile/le applicazioni incorporate essere sviluppate per essere conformi a MISRA-C? Qualcuno ha mai considerato un simile esercizio?

Il mio senso generale è che è necessario prima capire tutte le "regole" e quindi applicarle nella fase di progettazione/codifica. Potrebbero esserci istanze come le chiamate di sistema (pthread_create) e void * che devono essere forzate in conformità, producendo un codice dall'aspetto brutto.

Answer 1

Mentre MISRA-C è stato originariamente creato come standard solo per applicazioni automobilistiche e safety-critical, questo non è più vero. Oggigiorno MISRA-C è più uno standard generale che può essere usato per qualsiasi programma C in cui non sono desiderati problemi di bug, crash e portabilità.

È necessario chiedersi perché si sta utilizzando MISRA-C. È perché desideri usarlo come standard di codifica per sbarazzarti dei bug, o perché l'applicazione è di natura mission-critical?

Per il caso Linux, il problema principale sarà se si avrà il proprio codice MISRA compatibile, o se si richiederà che questo sia vero per tutte le librerie incluse. E non c'è proprio modo di rendere le librerie del kernel Linux + MISRA conformi, dovresti riscrivere Linux da zero.

Ciò rende Linux inadatto per software mission-critical. Ma se il tuo programma non è di natura mission-critical, dovresti essere in grado di usare Linux. Potresti dover scrivere in anticipo un numero di deviazioni in piedi da MISRA-C, perché ciò che puoi dire causerà problemi.

Answer 2

In una parola: No.

MISRA fornisce alcune buone linee guida, ma si sarebbe meglio solo cherry picking regole a cui si desidera aderire (ammesso che abbiate il check-in automatico la vostra analisi build/static).

Scorrendo tra le cose di MISRA-2004, ecco alcune aree problematiche.

Avere tutte le librerie conformi a MISRA è, di per sé, regola MISRA.

Norme in materia di goto, continue e break, funzione ritorna, e l'aritmetica dei puntatori sono violati in letteralmente miliardi di righe di codice sia kernel e userspace, quindi buona fortuna ottenere le librerie (o kernel) in conformità.

Le regole di trasmissione puntatore saranno impossibili da seguire se si utilizzano socket, tra le altre API comuni.

Misra 2004 11.2 conversioni non devono essere eseguite tra un puntatore di opporsi e qualsiasi tipo diverso da un tipo integrale, un altro puntatore a oggetto tipo o un puntatore a void .

2004-20.x sezioni divieto <errno.h>, <stdio.h>, <time.h> e <signal.h>. Segnali di divieto e controllo degli errori promuovono la programmazione BAD di Linux se si scrivono servizi affidabili e di lunga durata.

E nessuna allocazione di memoria dinamica è una regola da qualche parte.

So MISRA ha delle regole che consentono di violare le regole se li documentare (è questo vale per richiesto o semplicemente consulenza ???), ma avrete documentare soooo molte eccezioni che è davvero una sorta di inutile.

Detto questo, se hai un cliente che insiste sulla conformità MISRA (che è l'unica ragione per cui l'ho mai visto usato), potresti probabilmente documentare tutte le violazioni delle regole e fare qualche tentativo a mano di chiamarti MISRA conforme. Quindi potrebbe esserci un caso aziendale per fingere di essere conforme a MISRA su Linux, ma vedo poco o nessun vantaggio tecnico in esso.

ho paura che se si vuole essere veramente conforme e hanno bisogno di un/OS full-optional pesi massimi è meglio sborsare la pasta per QNX, GHS Integrità, VxWorks, ecc