EMBEDDED
54 • NOVEMBRE • 2014
70
SOFTWARE
C++
Non proprio adatto ai sistemi
safety-critical
Dopo aver enumerato i pro, ora veniamo ai contro del lin-
guaggio C++. La stessa ricchezza semantica, la potenza e
il grado di libertà in fase di sviluppo che C++ fornisce all’u-
tente può trasformarsi al contempo nella sua ‘debolezza’:
un’arma a doppio taglio, che esige maggior autodisciplina
e capacità di controllo da parte dello stesso sviluppatore.
In altri termini, C++ non rappresenta propriamente uno
strumento ideale da usare nella progettazione di applica-
zioni safety-critical, dove il software deve funzionare con
estrema affidabilità, in sistemi ‘delicati’ (sistemi automo-
tive, applicazioni militari, industriali, medicali), in cui un
malfunzionamento o un comportamento inatteso del codi-
ce può determinare conseguenze anche molto gravi e tra-
giche. Perché C++ non sarebbe adatto? Perché la natura
complessa di questo linguaggio incrementa la probabilità
di introdurre nel programma errori che non possono esse-
re identificati e segnalati da un compilatore.
Alcune strutture sintattiche di C++, e la sua semantica,
lasciano talvolta spazio ad ambiguità di interpretazione
(ad esempio, le ambiguità possibili nella chiamate delle
funzioni). Ambiguità che poi, a livello di compilazione, si
traducono e si riflettono in variazioni dei comportamenti
del programma a seconda del tipo di compilatore utilizza-
to. Da ciò si deduce l’importanza e la necessità di acquisi-
re una conoscenza più profonda possibile del linguaggio
C++, per evitare che la notevole complessità semantica
vada a ripercuotersi negativamente sul programma, con
l’insorgenza di un maggior numero di errori durante l’atti-
vità del compiler. Nello specifico caso dei sistemi embed-
ded che si rivelano critici per la sicurezza fisica – ossia le
applicazioni ‘safety-critical’, dai sistemi avionici, a quelli
medicali – occorre evitare quanto più è possibile l’uso di
costrutti e forme sintattiche del codice che portino a fun-
zionamenti imprevisti del software.
Standard e linee guida di codifica:
i riferimenti chiave
Nel tempo, una strategia indirizzata a ridurre la possibi-
lità di produrre difetti ed errori di programmazione nel-
lo sviluppo del codice, con il conseguente manifestarsi
di funzionamenti inattesi nel sistema embedded, è stata
l’adozione dei cosiddetti standard di codifica. Questi ul-
timi, in sostanza, puntano a canalizzare e concentrare le
funzionalità di C++ entro un insieme più ridotto di caratte-
ristiche e funzioni, che un programmatore può adoperare
con una ragionevole sicurezza, senza la preoccupazione di
generare errori e inconvenienti di vario tipo nel succes-
sivo comportamento del codice creato per una specifica
applicazione.
Tra i benefici chiave dell’utilizzo degli standard di codifica
non vi è soltanto un incremento della qualità e della manu-
tenibilità del codice: a guadagnarne è anche la velocità di
sviluppo, e il lavoro di gruppo, che può essere svolto con
maggior efficienza, grazie a una migliorata leggibilità dei
programmi.
Nello specifico settore dei sistemi embedded safety-cri-
tical, negli anni sono comparsi sulla scena diversi stan-
dard di codifica. Tra i più noti c’è, ad esempio, JSF AV
C++ (Joint Strike Fighter Air Vehicle C++) - lo standard
utilizzato per l’utilizzo di C++ nello sviluppo di software
avionico nell’ambito del programma JSF del dipartimento
della Difesa Usa. JSF C++ ha mutuato varie regole dal MI-
SRA-C (Motor Industry Software Reliability Association),
uno standard di codifica pubblicato per la prima volta nel
1998, rivisto nel 2004, e indirizzato a facilitare l’utilizzo
del linguaggio C nello sviluppo di sistemi safety-critical.
Tuttavia, la sempre maggiore tendenza a favorire la diffu-
sione e l’adozione di C++ per la progettazione di sistemi
safety-critical ha portato alla definizione, nel 2008, dello
standard di codifica MISRA-C++.
Un altro standard di codifica che fornisce regole e racco-
mandazioni per la codifica sicura è lo standard CERT C++.
Anch’esso punta all’obiettivo chiave di eliminare le prati-
che di codifica inaffidabili e i comportamenti indefiniti del
software, che possono portare alla formazione di vulnera-
bilità sfruttabili. Il principio base è sempre far leva su uno
standard di codifica sicuro, in grado di condurre alla cre-
azione di sistemi di più alta qualità, caratterizzati da una
maggior robustezza e resistenza ad attacchi e minacce.
Ancora, tra gli standard di codifica per C++, una posizione
di rilievo è occupata anche dallo standard High Integrity
C++ (HIC++), pubblicato in origine nel 2003 come un in-
sieme di 202 regole e linee guida semantiche e sintattiche,
ricavate da un subset ‘sicuro’ del linguaggio C (ISO C++
2003). Dopo oltre un decennio di attività, HIC++ ha ricevu-
to un aggiornamento importante con l’update HIC++ V4.0,
rilasciato verso la fine del 2013. Quest’ultimo ha compor-
tato il ritiro di 80 regole per varie ragioni specifiche, con
l’obiettivo generale di creare un insieme di regole più ap-
plicabile e gestibile.
Principi generali
Prima di passare all’analisi di alcune linee guida specifica-
te dai diversi standard di codifica, vale la pena fornire al-
cune indicazioni e consigli generali da seguire durante la
scrittura del codice. Un primo criterio fondamentale, volto
a favorire la leggibilità e chiarezza del codice, è imparare
a usare identificatori appropriati.
Un identificatore è una sequenza di caratteri che si usa
per definire un elemento del programma: ad esempio, il
nome di una variabile, di una funzione, di un oggetto o di
una classe. In C++ - che è un linguaggio ‘case sensitive’,