Background Image
Table of Contents Table of Contents
Previous Page  70 / 86 Next Page
Basic version Information
Show Menu
Previous Page 70 / 86 Next Page
Page Background

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’,