EMBEDDED
52 • MAGGIO • 2014
61
SOFTWARE
C LANGUAGE
• Il linguaggio dovrebbe essere definito in maniera
completa e senza ambiguità alcuna.
• Il linguaggio dovrebbe essere orientato all’utente o
al problema piuttosto che alla piattaforma e/o al proces-
sore. L’uso dei linguaggi che godono di più ampia diffu-
sione o i loro sottoinsiemi è preferito rispetto a quello
dei linguaggi per scopi specifici (special purpose).
• Il linguaggio dovrebbe favorire l’utilizzo di moduli
software di piccole dimensioni e facilmente gestibili;
la restrizione dell’accesso ai dati in moduli software
specifici, la definizione di sub-range (o sotto-intervalli)
di una variabile e ogni altro tipo di costrutto che ha lo
scopo di limitare gli errori.
A questo punto è utile esaminare
con attenzione le singole affermazio-
ni contenute nella definizione sopra
riportata e verificare se il linguaggio
C risulta conforme a tali affermazio-
ni:
• Il linguaggio dovrebbe esse-
re definito in maniera completa e
senza ambiguità alcuna: In questo
caso dipende dalla metrica utilizzata:
basti considerare il fatto che C99
contiene almeno 190 comportamenti non prevedibili.
• Il linguaggio dovrebbe essere orientato all’utente o
al problema piuttosto che alla piattaforma e/o al proces-
sore: In origine C è stato creato come linguaggio per
lo sviluppo di sistema per l’architettura PDP-11. Se si
tiene conto del fatto che un’implementazione C specifi-
ca per un target ben definito è necessariamente diversa
dall’implementazione per un altro target (e talvolta
differente anche da un’implementazione alternativa per
il medesimo target), si può dire a ragion veduta affer-
mare che il linguaggio C non risulta conforme a questa
definizione.
• L’uso dei linguaggi che godono di più ampia diffusio-
ne o i loro sottoinsiemi è preferito rispetto a quello dei
linguaggi per scopi specifici: nel caso del linguaggio C,
questa affermazione è vera. Vi è infatti un grandissimo
numero di sviluppatori che conoscono il linguaggio C e
alcuni dei suoi derivati come C++.
• Il linguaggio dovrebbe favorire l’utilizzo di moduli softwa-
re di piccole dimensioni e facilmente gestibili; la restrizione
dell’accesso ai dati in moduli software specifici, la definizio-
ne di sub-range (o intervalli) delle variabili e ogni altro tipo
di costrutti che hanno lo scopo di limitare gli errori: Sebbene
C non vieti in maniera esplicita la creazione di astrazioni
che supportano questi concetti, è corretto affermare che il
linguaggio stesso non fa assolutamente nulla per supportarli.
Infatti, si può anche sostenere che è vero l’esatto opposto.
Come si può dedurre, il linguaggio C non è all’altezza
delle aspettative definite dallo standard. A questo punto
è utile domandarsi in che modo è possibile superare il
problema.
La risposta, in realtà, è abbastanza semplice: continuan-
do nella lettura dello standard, si troverà una tabella
che esprime giudizi sui linguaggi specifici: nel caso del
linguaggio C il giudizio è quello riportato nella tabella 2.
Anche se C non è il linguaggio raccomandato, questo
stesso linguaggio con un adatto sottoinsieme (subset)
è persino caldamente raccomandato se usato insieme
a uno standard di codifica e a tool di
analisi statica. A questo punto è utile
capire il significato di subset e standard
di codifica in questo contesto.
Sottoinsieme dello standard
In questo contesto, lo scopo del sot-
toinsieme di un linguaggio è ridurre la
probabilità di errori di programmazione
e aumentare la probabilità di individuare
gli errori che in qualche modo si sono
insinuati nella base del codice. Nel caso
del linguaggio C, ciò significa elimi-
nare il maggior numero possibile di comportamenti
definiti dall’implementazione o non definiti. Esiste un
certo numero di questi sottoinsiemi del linguaggio e
il più conosciuto di questi è probabilmente MISRA-C.
L’insieme di regole di MISRA-C è un’iniziativa di Motor
Industry Software Reliability Association, un’associa-
zione con sede in UK, ed era inizialmente destinato
solamente al software usato in applicazioni nel settore
automotive. Nel corso degli anni le regole di MISRA-C
si sono diffuse a livello globale e in altri ambiti applica-
tivi: attualmente questo insieme di regole è il più diffuso
sottoinsieme del linguaggio C nel settore embedded.
Lo standard IEC61508 contiene molte informazioni
riguardanti le problematiche dello standard di codifica.
Di seguito sono riportati alcuni esempi di tematiche che
devono essere tenute in considerazione oltre alle regole
di MISRA-C:
• Come proteggere gli accessi alle risorse condivise
come le variabili globali.
• Modalità di utilizzo della memoria stack e della
memoria heap per l’allocazione degli oggetti.
• Possibilità o meno di effettuare la recursione
• Limiti di complessità, come ad esempio i limiti alla
complessità ciclomatica consentita per le funzioni.
• Come non tener conto delle regole MISRA-C che non
è possibile applicare in un certo contesto.
Nel caso
si voglia adottare
il linguaggio C
è necessario
trovare
un equilibrio
