Signal Handler come scrivere un signal handler in C - pt.2

Michele Apicella: Io lo so che tipo è lei: ha il suo macellaio di fiducia, che le tiene i pezzi migliori...
Bianca: Perché, c'è qualcosa di male?
Michele Apicella: E certo che c'è. Se ci vado io, poi mi prendo i pezzi peggiori!

Non so se ricordate, ma tempo fa scrissi un articolo sui signal handler, un argomento interessante, importante e, sfortunatamente, misconosciuto. Visto che ultimamente ho scritto alcuni signal handler  un po' sofisticati ho pensato che era il caso di scrivere una seconda parte, visto che nella prima avevo fornito informazioni (spero) complete sulle basi, descrivendo i segnali e i tipi di funzione usabili (e anche un esempio reale!), restando, però, sempre a "livello base", senza complicare troppo il discorso. E, quindi, ci vuole una seconda parte, no?

Io direi che adesso vi date un ripassino del vecchio articolo e poi tornate qua, pronti a vedere come si fa un signal handler  veramente professionale. Ah, dimenticavo; l'altra volta il film citato era Bianca del grande Nanni Moretti, quindi per non confondere le acque, ho scelto un bel dialogo (quello qui sopra) brillante e caustico come il film stesso (e come l'argomento del post, spero).

...E se il macellaio ha finito i migliori signal handler che faccio?...

Ok, dopo aver riletto il vecchio articolo dovreste avete ben chiaro cos'è e come si scrive un signal handler (che poi se eravate già esperti dell'argomento non cera bisogno di leggere quell'articolo e magari neanche questo, ah ah ah). Il vecchio esempio prevedeva un signal handler di due (2!) righe che maneggiava un flag (del tipo opportuno) e scriveva (nella maniera opportuna) un messaggio su stderr. E la preparazione del signal handler, anche questa super-semplificata, era scritta direttamente nel main del programma.

Ma un signal handler per una applicazione reale di produzione è possibile e probabile che debba fare più cose: ad esempio scrivere usando (correttamente) write(2) su stderr potrebbe essere insufficiente, dato che le applicazioni professionali di produzione a volte non hanno neanche una console, ma lavorano in background. Infatti un caso reale è scrivere sul syslog di sistema, ma bisogna farlo nella maniera opportuna, perché bisogna ricordare questo:

An async-signal-safe function is one that can be safely called from within 
a signal handler. Many functions are not async-signal-safe. In particular,
nonreentrant functions are generally unsafe to call from a signal handler.
                            da: signal-safety(7) Linux Programmer's Manual

una descrizione che, unita all'altra citazione che ho riportato nel vecchio articolo (quella da C Rationale, 7.14.1.1 [C99 Rationale 2003]), ci fa capire che dobbiamo andare coi piedi di piombo per scrivere nel syslog, ovvero: dobbiamo scriverci senza usare le funzioni della famiglia syslog(3)! (che, infatti sono funzioni NON async-signal-safe).

E come si può fare, allora? Beh, il trucco è il seguente: si può scrivere nel syslog usando lo stesso meccanismo che il demone Linux rsyslogd(8) usa internamente, e cioè scrivendo (con l'accortezza di usare solo funzioni async-signal-safe) sul un socket  aperto su /dev/log  (è un socket creato dallo stesso syslog di Linux alla partenza del sistema). 

Ma qui ci vuole, allora, un nuovo esempio! Ok, ho preso il codice del vecchio articolo e l'ho modificato nella maniera seguente:

1. Ho scritto una funzione sigHandler() che scrive sul socket  di /dev/log tramite write(2) che è una system-call async-signal-safe.
2. Ho scritto una funzione sigAction() che prepara le attività del signal handler in maniera un po' più sofisticata rispetto al vecchio esempio.
3. Ho scritto una funzione connectSyslog() che si connette al socket  di /dev/log.

Notare che il socket deve essere aperto usando una variabile locale di tipo volatile sig_atomic_t  che è l'unica compatibile con questo tipo di meccanismo (leggere la nota nel codice!). Notare anche che sigAction() e connectSyslog() possono anche contenere funzioni NON async-signal-safe (come fprintf(3)) perché si chiamano direttamente nel main, fuori dal signal handler.

Vai col codice!

#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <signal.h>
#include <sys/socket.h>
#include <sys/un.h>
#define SIGINT_MSG1 "<11>ricevuto un SIGSEGV/SIGINT/SIGBUS/SIGABRT. Esco con errore."
#define SIGINT_MSG2 "<11>ricevuto un SIGTERM. Esco correttamente."
// local prototypes
static void sigHandler(int signum);
static void sigAction();
static int  connectSyslog();
/* un flag per controllare il loop pseudo-infinito + una variabile per il socket.
   volatile potrebbe essere necessario a seconda del sistema/implementazione
   in uso. (vedere "C11 draft standard n1570: 5.1.2.3") */
static volatile sig_atomic_t resta_attivo = 1;
static volatile sig_atomic_t log_sock;
// main - funzione main
int main(int argc, char* argv[])
{
    // prepara il signal handler
    log_sock = connectSyslog();
    sigAction();
    // un loop pseudo-infinito per testare la applicazione
    while (resta_attivo)
        sleep(1);
    // il loop pseudo-infinito è stato interrotto da un SIGTERM
    printf("programma terminato correttamente\n");
    return 0;
}
// sigHandler - la funzione del signal handler
static void sigHandler(int signum)
{
    // salvo errno (un buon sighandler lo deve fare!)
    int my_errno = errno;
    // eseguo la azione necessaria (che normalmente è una exit)
    switch (signum) {
    case SIGSEGV:
    case SIGINT:
    case SIGBUS:
    case SIGABRT:
        // la applicazione esce perché il segnale è considerato causa di interruzione forzata
        write(log_sock, SIGINT_MSG1, sizeof(SIGINT_MSG1));
        _exit(signum);
    case SIGTERM:
        // set del flag "resta_attivo" per forzare l'uscita controllata del main loop
        write(log_sock, SIGINT_MSG2, sizeof(SIGINT_MSG2));
        resta_attivo = 0;
        break;
    default:
        break;
    }
    // ripristino l'errno
    errno = my_errno;
}
// sigAction - set delle azioni sui segnali da catturare
static void sigAction()
{
    // init dei dati di sigaction(2)
    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = sigHandler; // usa sa_handler per il signal handler
    sa.sa_flags   = SA_RESTART;
    // maschera tutti i segnali
    if (sigfillset(&sa.sa_mask) == -1)
        fprintf(stderr, "%s: sigfillset error: %s\n", __func__, strerror(errno));
    // set azioni per i segnali critici SIGSEGV, SIGINT, SIGBUS e SIGABRT
    if (sigaction(SIGSEGV, &sa, nullptr) == -1)
        fprintf(stderr, "%s: sigaction error for SIGSEGV: %s\n", __func__, strerror(errno));
    if (sigaction(SIGINT, &sa, nullptr) == -1)
        fprintf(stderr, "%s: sigaction error for SIGINT: %s\n", __func__, strerror(errno));
    if (sigaction(SIGBUS, &sa, nullptr) == -1)
        fprintf(stderr, "%s: sigaction error for SIGBUS: %s\n", __func__, strerror(errno));
    if (sigaction(SIGABRT, &sa, nullptr) == -1)
        fprintf(stderr, "%s: sigaction error for SIGABRT: %s\n", __func__, strerror(errno));
    // set azione per il segnale controllato SIGTERM
    if (sigaction(SIGTERM, &sa, nullptr) == -1)
        fprintf(stderr, "%s: sigaction error for SIGTERM: %s\n", __func__, strerror(errno));
}
// connectSyslog - collego il socket del syslog (/dev/log)
static int connectSyslog()
{
    // preparo la struct sockaddr_un per il collegamento via Unix Domain Socket
    struct sockaddr_un reader;
    memset(&reader, 0, sizeof(reader));
    reader.sun_family = AF_UNIX;
    snprintf(reader.sun_path, sizeof(reader.sun_path), "%s", "/dev/log");
    // provo a creare il socket in modo IPC Stream
    int log_sock;
    if ((log_sock = socket(AF_UNIX, SOCK_STREAM, 0)) != -1) {
        // connect to the syslog socket
        if (connect(log_sock, (struct sockaddr *)&reader, sizeof(reader)) != -1) {
            // successo della connect(2)
            return log_sock;
        } else {
            // errore connect(2)
            fprintf(stderr, "%s: STREAM connect error: %s\n", __func__, strerror(errno));
            close(log_sock);
        }
    }
    // errore IPC Stream: provo a creare il socket in modo IPC Datagram
    if ((log_sock = socket(AF_UNIX, SOCK_DGRAM, 0)) != -1) {
        // connect to the syslog socket
        if (connect(log_sock, (struct sockaddr *)&reader, sizeof(reader)) != -1) {
            // successo della connect(2)
            return log_sock;
        } else {
            // errore connect(2)
            fprintf(stderr, "%s: DGRAM connect error: %s\n", __func__, strerror(errno));
            close(log_sock);
        }
    }
    // connessione non effettuata
    return -1;
}

come avrete sicuramente notato, il codice è molto simile a quello del vecchio articolo ma con l'aggiunta dei punti descritti sopra. Ed è stra-commentato, quindi non è necessario aggiungere molte spiegazioni. Questa nuova versione scrive correttamente nel syslog, in base al tipo di segnale ricevuto, e quindi, se inviamo un SIGTERM (segnale 15) al PID dell'applicazione testsighandler:

aldo@Linux $ kill -15 64872
aldo@Linux $

la applicazione scriverà sul terminale :

aldo@Linux $ ./testsighandler
programma terminato correttamente
aldo@Linux $

e il syslog registrerà questa linea in /var/log/syslog:

2025-06-25T16:22:39.383661+02:00 Linux ricevuto un SIGTERM. Esco correttamente.

Mentre se inviamo all'applicazione uno dei segnali "trappati"  come errori irrecuperabili (SIGSEGV, SIGINT, ecc.) succederà questo (usando, ad esempio un SIGBUS (segnale 7)):

aldo@Linux $ kill -7 65071
aldo@Linux $

La applicazione uscirà senza scrivere nulla sul terminale e il syslog registrerà questa linea in /var/log/syslog:

2025-06-25T16:22:57.535779+02:00 Linux ricevuto un SIGSEGV/SIGINT/SIGBUS/SIGABRT. Esco con errore.

Io direi che funziona bene, no? E, teoricamente, con questo avremmo finito, ma... In realtà potrebbe essere necessario complicare ulteriormente il codice per alcune esigenze particolari. Ad esempio:

1. Si può verificare sperimentalmente che, su alcuni sistemi Linux non completamente "canonici"  (come alcune implementazioni embedded oppure il terribile WSL), se viene fatto un restart del processo rsyslogd il signal handler appena visto non riesce più a scriver sul socket del syslog. Invece sui sistemi Linux standard (Mint, Ubuntu, ecc.) il problema non si presenta.
2. In alcuni casi potrebbe essere necessario aggiungere dettagli "dinamici"  nelle stringhe destinate al syslog, ma come farlo senza usare, ad esempio, la snprintf(3)?

Ecco, nella terza parte dell'articolo (ebbene si! Ci sarà una terza parte!) vi mostrerò come risolvere i due problemini appena elencati. Ma mi raccomando: non trattenete il respiro nell'attesa! (può nuocere gravemente alla salute, ah ah ah).

Ciao, e al prossimo post!

Il buono, il brutto, il VLA come usare i Variable Length Array in C - pt.3

Tuco (il brutto): Il mondo è diviso in due, amico mio: quelli che hanno la corda al collo e quelli che la tagliano. Solo che il collo dentro la corda è il mio, sono io che rischio, perciò la prossima volta voglio più della metà.
Biondo (il buono): Sì, è vero che tu rischi. Ma io taglio e se tu mi abbassi la percentuale... sigaro? ... potrei sbagliare la mira.

(...una premessa: questo post è un remake di un mio vecchio post (parte 3 di 3). Ma, anche se tratta lo stesso argomento, amplia e perfeziona un po' il discorso è mi è sembrato il caso di riproporlo. Leggete e mi direte...)

Dunque, dove eravamo rimasti? Ah si, nel primo articolo della serie (che avete appena riletto, vero?), avevamo approvato, con riserva, i Variable Length Array (VLA per gli amici), che sono facili da usare, utili e con ottime prestazioni. Poi, nel secondo articolo (anche quello è da rileggere, eh!), avevamo, ahimè, confermato la riserva assegnandogli il ruolo del cattivo del mitico Il buono, il brutto, il cattivo del grande Sergio Leone, e questo perché i contro dei VLA superavano ampliamene i pro. Ed ora eccoci di nuovo sul pezzo e, come promesso, oggi parleremo di un parente stretto dei VLA, ovvero della funzione alloca(3)... sarà un buono, un brutto o un cattivo?

...ciao, sono lo spoiler di questo post!...

E allora: ho aggiunto del codice al programma di test (visto nei precedenti articoli) per provare la alloca(3). E, per non farci mancare niente, ho aggiunto anche del codice per provare la versione C++ della malloc(3), ovvero la new (ebbene si: dopo il problematico test di std::vector dello scorso post era doveroso parlare anche di qualcosa più prestante, mica si dica che ce l'ho con il C++...). Quindi useremo il programma C++ già proposto (tanto era praticamente identico alla versione C) di cui vi riporterò solamente il main() e le due funzioni di test aggiunte (e, per ricostruire il programma completo, basta consultare i due post precedenti e fare un po' di copia-e-incolla). Vai col codice!

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <vector>
#define MYSIZE  1000000
// variabile dummy per evitare lo svuotamento totale delle funzioni usando g++ -O2
int avoid_optimization;
// prototipi locali
void runTest(int iterations, void (*funcptr)(int), int size, const char *name);
void testVLA(int size);
void testMallocVLA(int size);
void testStackFLA(int dum);
void testHeapFLA(int dum);
void testAllocaVLA(int size);
void testVectorVLA(int size);
void testNewVLA(int size);
// funzione main()
int main(int argc, char* argv[])
{
    // test argomenti
    if (argc != 2) {
        // errore: conteggio argomenti errato
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s vla iterations [e.g.: %s 10000]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }
    // estrae iterazioni
    int iterations = atoi(argv[1]);
    // esegue test
    runTest(iterations, &testVLA, MYSIZE, "testVLA");
    runTest(iterations, &testMallocVLA, MYSIZE, "testMallocVLA");
    runTest(iterations, &testStackFLA, 0, "testStackFLA");
    runTest(iterations, &testHeapFLA, 0, "testHeapFLA");
    runTest(iterations, &testAllocaVLA, MYSIZE, "testAllocaVLA");
    runTest(iterations, &testVectorVLA, MYSIZE, "testVectorVLA");
    runTest(iterations, &testNewVLA, MYSIZE, "testNewVLA");
    // esce
    return EXIT_SUCCESS;
}
// testAllocaVLA() - funzione per eseguire il test della alloca VLA
void testAllocaVLA(
    int size)       // size per alloca()
{
    int *allocavla = (int*)alloca(size * sizeof(int));
    // loop di test
    for (int i = 0; i < size; i++)
        allocavla[i] = i;
    // istruzione per evitare lo svuotamento totale della funzione usando g++ -O2
    avoid_optimization = allocavla[size / 2];
}
// testNewVLA() - funzione per eseguire il test della new VLA
void testNewVLA(
    int size)       // size per new
{
    int *newvla = new int[size];
    // loop di test
    for (int i = 0; i < size; i++)
        newvla[i] = i;
    // istruzione per evitare lo svuotamento totale della funzione usando g++ -O2
    avoid_optimization = newvla[size / 2];
    delete[] newvla;
}

Come potete vedere, le due funzioni aggiunte sono perfettamente allineate stilisticamente con le altre che avevo già proposto e sono, come sempre, iper-commentate, così non c'è neanche bisogno di dilungarmi in spiegazioni. E i risultati del test? Vediamoli!

aldo@Linux $ g++ -O0 vlacpp.cpp -o vlacpp
aldo@Linux $ ./vlacpp 2000
testVLA       -  Tempo trascorso: 3.908325 secondi
testMallocVLA -  Tempo trascorso: 2.724537 secondi
testStackFLA  -  Tempo trascorso: 3.631790 secondi
testHeapFLA   -  Tempo trascorso: 3.623486 secondi
testAllocaVLA -  Tempo trascorso: 2.751826 secondi
testVectorVLA -  Tempo trascorso: 8.930886 secondi
testNewVLA    -  Tempo trascorso: 2.752857 secondi
aldo@Linux $ g++ -O2 vlacpp.cpp -o vlacpp
aldo@Linux $ ./vlacpp 2000
testVLA       -  Tempo trascorso: 0.633613 secondi
testMallocVLA -  Tempo trascorso: 0.627741 secondi
testStackFLA  -  Tempo trascorso: 0.267571 secondi
testHeapFLA   -  Tempo trascorso: 0.263820 secondi
testAllocaVLA -  Tempo trascorso: 0.623920 secondi
testVectorVLA -  Tempo trascorso: 0.773795 secondi
testNewVLA    -  Tempo trascorso: 0.613130 secondi

Allora, cosa si può dire? I risultati dei test dei post precedenti li abbiamo già ampiamente commentati, quindi ora possiamo solo aggiungere questo: alloca(3) è molto veloce, visto che è, in pratica, una malloc(3) nello stack (e, usandola in maniera appropriata, potrebbe/dovrebbe essere la più veloce del gruppo). E la new? Beh, si comporta (come previsto) benissimo, anche perché, spesso, la new usa internamente la malloc(3).

E va bene: la alloca(3) è veloce, ma lo è (solo un po' meno) anche un VLA, e questo non lo ha salvato dal essere eletto come cattivo nello scorso articolo Quindi ci toccherà fare di nuovo una lista di pro e contro, e vedere quale parte pesa di più. Vediamo prima i pro:

1. La alloca(3) è molto veloce, già che usa lo stack invece del heap.
2. È anche facile da usare, visto che è, praticamente, una malloc(3) senza free(3). La variabile allocata ha uno scope a livello di funzione, quindi rimane valida fino a quando la funzione ritorna al chiamante, esattamente come una qualsiasi variabile automatica locale (anche un VLA funziona più o meno così, ma il suo scope è a livello di blocco, non di funzione, e questo è, probabilmente, un punto a favore dei VLA).
3. Per il motivo visto al punto 2 la alloca(3) non lascia in giro residui di memoria in caso di errori gravi nella attività di una funzione (e con malloc + free non è altrettanto facile realizzare questo). Se poi siete soliti a usare cosucce come longjmp(3) i vantaggi in questo senso sono grandissimi.
4. A causa della sua implementazione interna (senza entrare in dettagli profondi) la alloca(3) non causa frammentazione della memoria.

Uh, che bello! E i contro?

1. La gestione degli errori è problematica, perché non c'è maniera di sapere se alloca(3) ha allocato bene o ha provocato un stack overflow (in questo caso provoca effetti simili a quelli di un errore per ricorsione infinita)... uh, questo è esattamente lo stesso problema dei VLA.
2. Non è molto portabile, visto che non è una funzione standard e il suo funzionamento e la sua presenza dipendono molto dal compilatore in uso.
3. È error prone per almeno tre motivi:

• • Bisogna usarla con attenzione, visto che induce, tipicamente, a errori come usare la variabile allocata quando oramai non è più valida (ritornarla o inserirla dentro una struttura dati esterna alla funzione, per esempio)... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?
  • Ci sono problemi ancora più sottili da considerare nell'uso, ad esempio può risultare MOLTO pericoloso mettere una alloca(3) dentro un loop o in una funzione ricorsiva  (povero stack!) oppure in una funzione inline (visto che una inline usa lo stack in una maniera che si scontra un po' con la maniera di usare lo stack della alloca(3))... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?
  • Usa lo stack, che è normalmente limitato rispetto allo heap (specialmente nella programmazione embedded che è molto frequentata dai programmatori C...). Quindi esaurire lo stack e provocare uno stack overflow è facile (e difficile da controllare, vedi il punto 1)... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?

E vabbè, conclusioni? Ci sarebbero gli estremi per dichiarare la alloca(3) come un altro cattivo (la stessa sorte dei VLA) ma, dati i notevoli pro e, soprattutto, dato che oggi sono di buon umore, la dichiareremo solo come brutto (visto lo spoiler nella figura iniziale?). Comunque, mi raccomando: usate la alloca(3) con molta cautela, uomo avvisato mezzo salvato!

Ciao e al prossimo post! 

Il buono, il brutto, il VLA come usare i Variable Length Array in C - pt.2

Biondo (il buono): [contando gli uomini di Sentenza] Uno, due, tre, quattro, cinque, sei... Sei, il numero perfetto!
Sentenza (il cattivo): Non è tre il numero perfetto?
Biondo (il buono): Sì, ma io ho sei colpi qui dentro...

(...una premessa: questo post è un remake di un mio vecchio post (parte 2 di 3). Ma, anche se tratta lo stesso argomento, amplia e perfeziona un po' il discorso è mi è sembrato il caso di riproporlo. Leggete e mi direte...)

Dunque, dove eravamo rimasti? Ah si, nell'ultimo articolo (che avete appena riletto, vero?) avevamo approvato (con riserva) i Variable Length Array (VLA per gli amici), che sono facili da usare, utili e con ottime prestazioni, ma allora... perché ho detto che sono adatti al ruolo del cattivo nel mitico Il buono, il brutto, il cattivo del grande Sergio Leone?

...non fidatevi del VLA, parola del buono!...

Presto detto: oltre ai (notevoli) pro ci sono anche alcuni (pesanti) contro. Prima di seguire ricordiamoci sempre che un VLA si alloca dinamicamente nello stack come una variabile automatica con scope limitato al blocco di codice dove avviene l'allocazione: dopodiché i (principali) possibili problemi sono:

1. la gestione degli errori è problematica, perché non c'è maniera di sapere se il VLA è stato allocato bene o ha provocato un stack overflow  (in questo caso provoca effetti simili a quelli di un errore per ricorsione infinita).
2. il size del VLA si decide a run-time, quindi il compilatore deve fare dei giochi un po' strani: in base all'implementazione è possibile che una parte (anche importante) dello stack di una funzione venga riservato per un VLA, limitando molto la memoria locale disponibile. Quindi lo stack overflow è sempre dietro l'angolo.
3. la portabilità del codice va un po' a farsi benedire: il codice diventa molto compiler-dependent  e, soprattutto, visto che una buona fetta di programmatori C scrivono anche codice per sistemi embedded (dove lo stack è, spesso, limitato) risulta complicato il porting di funzioni da applicazioni normali  ad applicazioni embedded. Funzioni che, magari, smetterebbero di funzionare per motivi misteriosi (beh, neanche tanto misteriosi...).
4. E, dulcis in fundo: forse per i motivi appena elencati (o per altri ancora) da C11 in avanti i VLA sono opzionali e subordinati al flag __STDC_NO_VLA__ del compilatore, e questo è un brutto segno.

Che fare allora? Meglio non usarli o usarli con le precauzioni del caso, anche perché le alternative non mancano. E, con questo, abbiamo trovato il Cattivo!

E adesso ci tocca cercare qualcuno che sia adatto ai ruoli del buono e del brutto. Ecco, per il buono non c'è problema, il candidato ideale è la cara, buona, vecchia malloc(3) che è sempre una garanzia ed è uscita molto bene dal test. Sulla malloc(3) è inutile dilungarci, è un punto fermo del C e ne abbiamo già parlato abbondantemente qui.

E il brutto? Beh, per cercare uno adatto dovremo, ahimè, addentrarci nel lato oscuro della forza, e cioè in territorio C++...

(...apro una parentesi: non parlo mai di argomenti che non conosco, perché penso che sia stupido farlo. Per fare un esempio: io non capisco niente di moto e, vi assicuro, nessuno ha mai avuto l'onore di sentirmi disquisire sul mondiale di MotoGP. Seguo una filosofia che, sfortunatamente, non è seguita da molta gente, è cioè: "mai parlare solo per dare aria alla bocca". Proprio in virtù di questa coerenza penso di avere i titoli per parlare del C++: lo uso in parallelo al mio amato C da circa trenta (!) anni, e, modestia a parte, penso di saperlo usare bene. Quindi ne posso disquisire, nel bene e nel male. Chiudo la parentesi...).

Allora, ho ripreso pari pari l'esempio C del post precedente e (facendo il minimo sindacale di modifiche) l'ho trasformato in codice C++, per poter, così, aggiungere un test nuovo che usa std::vector (questo è un oggetto particolarmente caro ai C++ lovers, che lo usano anche per condire l'insalata). Per non ripetere tutto il codice dello scorso post vi riporto solo il main() e la nuova funzione di test aggiunta (il resto è, praticamente, invariato). Vai col codice!

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <vector>
#define MYSIZE  1000000
// variabile dummy per evitare lo svuotamento totale delle funzioni usando g++ -O2
int avoid_optimization;
// prototipi locali
void runTest(int iterations, void (*funcptr)(int), int size, const char *name);
void testVLA(int size);
void testMallocVLA(int size);
void testStackFLA(int dum);
void testHeapFLA(int dum);
void testVectorVLA(int size);
// funzione main()
int main(int argc, char* argv[])
{
    // test argomenti
    if (argc != 2) {
        // errore: conteggio argomenti errato
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s vla iterations [e.g.: %s 10000]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }
    // estrae iterazioni
    int iterations = atoi(argv[1]);
    // esegue test
    runTest(iterations, &testVLA, MYSIZE, "testVLA");
    runTest(iterations, &testMallocVLA, MYSIZE, "testMallocVLA");
    runTest(iterations, &testStackFLA, 0, "testStackFLA");
    runTest(iterations, &testHeapFLA, 0, "testHeapFLA");
    runTest(iterations, &testVectorVLA, MYSIZE, "testVectorVLA");
    // esce
    return EXIT_SUCCESS;
}
// testVectorVLA() - funzione per eseguire il test del vector VLA
void testVectorVLA(
    int size)       // size per std::vector
{
    std::vector<int> vectorvla(size);
    // loop di test
    for (int i = 0; i < size; i++)
        vectorvla[i] = i;
    // istruzione per evitare lo svuotamento totale della funzione usando g++ -O2
    avoid_optimization = vectorvla[size / 2];
}

Compilando (con/senza ottimizzazioni) ed eseguendo questo codice i risultati sono i seguenti:

aldo@Linux $ g++ -O0 vlacpp.cpp -o vlacpp
aldo@Linux $ ./vlacpp 2000
testVLA       -  Tempo trascorso: 3.912879 secondi
testMallocVLA -  Tempo trascorso: 2.727576 secondi
testStackFLA  -  Tempo trascorso: 3.662505 secondi
testHeapFLA   -  Tempo trascorso: 3.625115 secondi
testVectorVLA -  Tempo trascorso: 8.964794 secondi
aldo@Linux $ g++ -O2 vlacpp.cpp -o vlacpp
aldo@Linux $ ./vlacpp 2000
testVLA       -  Tempo trascorso: 0.630394 secondi
testMallocVLA -  Tempo trascorso: 0.615095 secondi
testStackFLA  -  Tempo trascorso: 0.218578 secondi
testHeapFLA   -  Tempo trascorso: 0.208932 secondi
testVectorVLA -  Tempo trascorso: 0.773074 secondi

E, allora, come si è comportato std::vector ? direi che i numeri parlano da soli, quindi abbiamo un buon candidato per il ruolo del brutto... ma vabbè, mettiamola giù in maniera diplomatica: diciamo che abbiamo due notizie, una buona e una cattiva:

• la buona notizia è che il C++ è efficiente come il C (e su questo non avevo dubbi), infatti il nostro programma C trasformato in C++ ottiene (nei primi quattro test) le stesse prestazioni (andate a controllare là, se non ci credete, eh!).
• la brutta notizia è che il C++ è efficiente come il C, ma solo se lo usate come il C, quindi niente STL e ammennicoli vari. Ma, comunque, con l'ottimizzazione attivata, anche std::vector  funzionicchia...

(...apro un altra parentesi: ovviamente la brutta notizia qui sopra non deriva solo dal semplice test proposto in questo post: deriva da anni ed anni di osservazioni ed uso intensivo di entrambi i linguaggi, ci mancherebbe solo. Chiudo la parentesi...).

E, visto quanto sopra, credo che sia il caso di esporre (brevemente) una mia opinione: il C++ è un grande linguaggio potente, efficiente ed espressivo (è parente stretto del C!), con cui si può scrivere del Software di alta qualità. Ma i risultati migliori (perlomeno in termini di prestazioni e fluidità del codice) si ottengono usandolo per quello che era stato concepito originalmente, e cioè come un semplice C a oggetti. La piega che ha preso in seguito (da quando è caduto nelle mani dei malefici committee ISO) non mi piace e non mi convince... ma, fortunatamente (e questo è importante), continua a poter essere usato nella sua essenza, quella che permette di scrivere a oggetti usando un linguaggio (quasi) identico al C (e questo si aggancia alla buona notizia qui sopra... e do per scontato che prestazioni e fluidità del codice siano estremamente importanti, eh!).

Ah, una ultima precisazione per chi si è sorpreso del codice C++ (qui sopra) che include un VLA: è una gentile offerta dal nostro amato GCC (nella sua incarnazione g++). Quindi è un estensione del linguaggio fornita dal compilatore, visto che i VLA non fanno parte del C++ standard (almeno fino a C++14).

Nel prossimo post, per chiudere il cerchio, parleremo di un parente stretto dei VLA, e cioè della funzione alloca(3). Sarà un altro buono, un altro brutto o un altro cattivo?

Ciao e al prossimo post!