EMBEDDED
52 • MAGGIO • 2014
59
SOFTWARE
C LANGUAGE
el 1991 la rivista “Developer’s Insight” ha
pubblicato un divertente articolo dal titolo
“How to Shoot Yourself In the Foot” nel
quale si affermava tra l’altro: “La prolifera-
zione dei moderni linguaggi di programma-
zione – ciascuno dei quali sembra avere un gran numero
di caratteristiche prese a prestito dagli altri – fa sì che
talvolta risulti difficile per i programmatori ricordarsi
quale linguaggio stiano utilizzando. Questa guida vuole
essere una sorta di servizio a disposizione dei program-
matori che si trovano ad affrontare tale dilemma”.
L’elenco iniziava con il linguaggio C e affermava molto
sinteticamente:
• C – Vi state facendo del male da soli.
Questo verdetto, anche se può apparire molto severo,
contiene alcuni frammenti di verità. In ogni caso, anche
se linguaggi di programmazione alternativi possono
essere afflitti da un numero inferiore di problemi in ter-
mini, ad esempio, di sicurezza rispetto ai tipi (type safe-
ty – ovvero la misura con cui un linguaggio di program-
mazione previene o avvisa rispetto agli errori di tipo)
o comportamento non prevedibile a priori (undefined
behavior), spesso non hanno le caratteristiche richieste
per la programmazione “close to the metal” (ovvero che
permetta di interfacciarsi alle componenti hardware nel
modo più diretto possibile per sfruttarne la massimo
le potenzialità teoriche). Nel caso si voglia adottare il
linguaggio C è necessario trovare un equilibrio: gestire
in maniera adeguata i “trabocchetti” più o meno ovvi
di questo linguaggio e sfruttare al meglio le sue carat-
teristiche. È possibile valutare l’uso del linguaggio C
per lo sviluppo di funzionalità “safety-critical” sotto due
differenti punti di vista:
• Quali sono i requisiti esterni in un progetto “safety
critical” rispetto alla scelta del linguaggio di program-
mazione?
• Cosa si può fare per porre rimedio ad alcuni dei più
evidenti problemi legati all’uso del linguaggio C, anche
quando si sta lavorando con codice legacy?
Il ruolo degli standard
Se i prodotti su cui si sta lavorando sono destinati all’u-
so in applicazioni in ambito automobilistico, oppure del
controllo industriale, dei dispositivi medicali o ferrovia-
ri esistono buone probabilità che debbano soddisfare
requisiti di sicurezza funzionale formale. Essi possono
ridursi a un requisito specifico relativo al tasso di
guasto tollerato del prodotto oppure al tasso di guasto
N
Come “neutralizzare”
alcuni dei pericoli
intrinseci
del linguaggio C
Scopo di questo articolo è analizzare i problemi connessi all’uso del linguaggio C nello sviluppo di sistemi
con funzionalità “safety-critical”. Nonostante i suoi limiti, come ad esempio comportamento non definito,
dipendenza dall’hardware e così via, questo linguaggio è ancora ampiamente utilizzato nello sviluppo di
applicazioni critiche dal punto di vista della sicurezza. Con un’opportuna pianificazione e usando qualche
avvertenza è possibile trasformare un potenziale problema in un’opportunità
Anders Holmberg
Product manager
IAR Systems
