La NSA sconsiglia l’uso di C e C++ come linguaggio e Bjarne Stroustrup risponde per le rime!

Bjarne Stroustrup è un nome poco noto al grande pubblico, eppure è quasi sicuro che ogni giorno utilizziate un programma scritto nel linguaggio di cui è il papà.

Stroustrup, infatti, è l’ideatore di C++. Pensato come superset del linguaggio C per dotare quest’ultimo della programmazione orientata agli oggetti, dagli anni novanta è stato utilizzato per scrivere la vasta maggioranza dei programmi che usiamo oggi. Chrome, Firefox, Adobe e l’intero KDE-Plasma sono scritti in C++, giusto per citarne alcuni.

Oggetto dell’articolo di oggi è la risposta data da Stroustrup alla pubblicazione delle nuove linee guida di sviluppo per chi produce software per NSA, la National Security Agency. Nel rapporto, si dice:

Commonly used languages, such as C and C++, provide a lot of freedom and flexibilityin memory management while relying heavily on the programmer to perform the needed checks on memory references. Simple mistakes can lead to exploitable memory-based
vulnerabilities. Software analysis tools can detect many instances of memory management issues and operating environment options can also provide some protection, but inherent protections offered by memory safe software languages can prevent or mitigate most memory management issues. NSA recommends using a memory safe language when possible

Linguaggi comunemente utilizzati, come C e C++, forniscono molta libertà e flessibilità circa la gestione della memoria, ma dipendono pesantemente sul programmatore circa l’effettuare i controlli necessari sui puntatori nella memoria. Semplici errori possono condurre a vulnerabilità basate sulla memoria sfruttabili (a un attacco informatico, ndr).
Software di analisi possono individuare diverse situazioni problematiche nella gestione della memoria e alcune opzioni dell’ambiente operativo possono fornire una qualche protezione, ma protezioni integrate offerte da linguaggi memory safe possono prevenire o mitigare la maggior parte dei problemi legati alla gestione della memoria. La NSA raccomanda di usare un linguaggio memory safe quando è possibile.

La reazione di Stroustrup non si è fatta attendere e in un articolo ha difeso la sua creatura e gli sforzi fatti negli anni per rendere il C++ un linguaggio più sicuro. Per chi si è fermato agli anni ’90, ricordo alcune innovazioni presenti nel linguaggio:

1. gli smart-pointer per gestire la memoria: new e delete sono cose del passato;
2. le librerie ufficiali per gestire i thread e i relativi lock;
3. std::vector, std::map e std::string rimpiazzano le vecchie e insicure strutture dati e le stringhe ereditate dal C;
4. un memory-model da C++14 (spiegazione nel link);
5. il construtto foreach per iterare su tutti gli elementi di una struttura dati senza doversi preoccupare delle condizioni di uscita, come sarebbe con for e con while;
6. la keyword auto che permette di dichiarare una variabile senza specificarne il tipo. Utile quando avete da gestire tanti template annidati:

// una dichiarazione lunghissima... std::unique_ptr<std::map<std::string,std::shared_ptr<MyObject>> = std::make_unique(std::map<std::string,std::shared_ptr<MyObject>>); // ...diventa così! auto mymap = std::make_unique(std::map<std::string,std::shared_ptr<MyObject>>); // e per effettuare un ciclo su questa struttura dati, avremmo foreach(auto m : mymap) { auto value = m.second; ... } // anziché lavorare direttamente con gli iteratori

Insomma, tanta roba, tant’è che Stroustrup lo dice in una risposta pubblicata online a difesa della sua creatura.

I have worked for decades to make it possible to write better, safer, and more efficient C++.

Ho lavorato per decenni per rendere possibile lo scrivere migliore, più sicuro e più efficiente (software, nrd) C++

Che il C++ sia cambiato tantissimo negli ultimi anni è un fatto: solo con i costrutti introdotti dallo standard nel 2011, abbiamo la possibilità di evitare completamente i temuti memory leaks e di avere una sintassi che è più vicina a noi. Quindi, perché NSA non ha ammesso il C++ tra i linguaggi adatti ai suoi scopi?

Per chi lavora con C++ ogni giorno il problema è probabilmente legato alla forma mentis di chi utilizza questo linguaggio: esistono discussioni se sia più veloce in esecuzione l’uso di un puntatore unique o shared, quando la differenza non si misura nemmeno in millisecondi, ma in frazioni di millisecondo. Lo stesso succede quando si trovano persone che preferiscono l’uso di atomic piuttosto che di un mutex per gestire la sezione critica, quando la differenza si potrebbe notare solo in ambiti hard real-time e mission critical del calibro di radar militari, centrali nucleari e sottomarini.

Per esperienza, se pensate di utilizzare il C++ per il vostro prossimo progetto, fate pure: il linguaggio è solido, ha milioni di librerie e con le features moderne è anche ragionevolmente memory safe. Ma non effettuate ottimizzazioni premature con costrutti che mettono a repentaglio la stabilità del programma. Le ottimizzazioni si fanno dopo aver misurato dove si trovano i colli di bottiglia.

Dopotutto, tutti i fan del C++ sanno usare Valgrind, vero? 🙂