Buone Feste!

I Misteri delle Funzioni del C come funzionano alcune funzioni speciali in C - pt.2

Sig.ra Talmann: Il tuo discorso, Louis, sta diventando meteorologico.

È giunto il momento di tornare su I misteri del giardino di Compton House, anzi meglio, sulla seconda parte de I Misteri delle Funzioni del C (...e una ripassatina alla prima parte non ci starebbe male, prima di proseguire...). E giuro che cercherò di non cadere in discorsi meteorologici e incomprensibili come Louis Talmann.

...misteri? Quali misteri?...

(...una doverosa premessa: sicuramente per qualcuno, o per molti, i misteri trattati nella prima parte e, probabilmente, anche questi della seconda non sono affatto misteri. Ma voglio ribadire quanto già detto nella prima parte: girando su vari siti di programmazione (tipo l'ottimo stackoverflow, per intenderci), si nota che anche programmatori "scafati" hanno, a volte, dubbi su concetti di base (e chi non ne ha mai avuti scagli la prima pietra!) e poi, più in generale, la lettura di "un altra campana tecnica" può risultare sempre interessante, dando per scontato che la "curiosità tecnologica" è una dote che dovrebbe (anzi, deve!) essere sempre presente negli appassionati di programmazione. Che poi, se uno questa curiosità non ce l'ha... va beh, meglio fermarsi qui, No Comment...) 

Veniamo al dunque: dopo aver visto i primi tre misteri e cioè 1.Il mistero delle funzioni con un parametro array, 2.Il mistero delle funzioni che restituiscono una stringa letterale e 3.Il mistero delle funzioni che restituiscono un char pointer direi che il quarto mistero è quasi scontato, ed è:

4) Il mistero delle funzioni che restituiscono un void pointer
Nella libc ci sono un bel po' di funzioni che restituiscono un void* (per gli amici "void star"), come ad esempio quelle delle famiglia mem (memcpy(), memccpy(), ecc.). Come sono fatte? Ci sono alternative valide alla struttura "classica"? Vediamo un semplice esempio con una implementazione minimale della memcpy(), senza controlli, senza ottimizzazioni, senza tutto, ma per un esempio è più che sufficiente. Vediamo il codice, che anche in questo caso include un piccolo e semplice main() di test:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// prototipi locali
void *myMemcpy(void *dest, const void *src, size_t len);
void *myMemcpyMalloc(void *dest, const void *src, size_t len);

// funzione main
int main(int argc, char *argv[])
{
    // eseguo myMemcpy() e mostro il risultato
    char *src1 = "pluto";
    char dest1[32];
    myMemcpy(dest1, src1, strlen(src1) + 1);
    dest1[strlen(src1)] = 0;    // ricordarsi del terminatore se copiamo una stringa
    printf("myMemcpy(): dest = %s\n", dest1);

    // eseguo myMemcpyMalloc() e mostro il risultato
    char *src2 = "minnie";
    char *dest2 = myMemcpyMalloc(dest2, src2, strlen(src2) + 1);
    dest2[strlen(src2)] = 0;    // ricordarsi del terminatore se copiamo una stringa
    printf("myMemcpyMalloc(): dest = %s\n", dest2);
    free(dest2);                // ricordarsi di questa free()

    return 0;
}

// myMemcpy - versione semplificata della memcpy() della libc
void *myMemcpy(void *dest, const void *src, size_t len)
{
    // salvo localmente dest e src ed eseguo un recast a char*
    char *my_dest = (char *)dest;
    const char *my_src  = (const char *)src;

    // copio la copia locale di src sulla copia locale di dest (copio solo <len> caratteri)
    while (len--)
        *my_dest++ = *my_src++;

    // ritorno il dest salvato
    return dest;
}

// myMemcpyMalloc - versione con malloc interna di myMemcpy()
void *myMemcpyMalloc(void *dest, const void *src, size_t len)
{
    // alloco dest (N.B.: la free() la deve fare il chiamante della myMemcpyMalloc())
    dest = malloc(len);

    // salvo localmente dest e src ed eseguo un recast a char*
    char *my_dest = (char *)dest;
    const char *my_src  = (const char *)src;

    // copio la copia locale di src sulla copia locale di dest (copio solo <len> caratteri)
    while (len--)
        *my_dest++ = *my_src++;

    // ritorno il dest salvato
    return dest;
}

Anche in questo caso il meccanismo è semplice e quasi identico a quello della strncpy() mostrato nella parte 1 dell'articolo. Senza entrare di nuovo nei dettagli (per non ripeterci, e poi il codice è ben commentato), notiamo che la unica differenza vera è che la copia viene eseguita usando copie locali di src e dest "ricastate" a char: perché? La riposta è semplice: questo tipo di funzioni accettano parametri generici (grazie all'uso di void*), quindi si possono passare pointer a strutture, array, ecc. Ma poi, internamente, la copia si fa byte-a-byte, per cui si riconduce tutto al (magico) tipo char*. E, ovviamente, si ritorna sempre l'argomento dest originale, per i motivi già descritti sopra. E anche in questo caso ho pensato di aggiungere una memcpy() poco canonica, con allocazione interna, per la quale valgono tutte le considerazione fatte per la myStrncpyMalloc() già descritta.

Notare che, per coerenza con gli esempi della prima parte del post (e anche per mostrare con semplicità un risultato pratico) ho usato le due myMemcpy() per copiare una stringa (non è un uso classico, ma chi lo vieta?). Ovviamente ho provveduto, a livello main(), ad aggiungere un string terminator, visto che la myMemcpy() a differenza della myStrncpy() già vista, non può (anzi, non deve) pensare a eventuali terminatori di stringa già che è una funzione generica di copia di memoria.

E adesso possiamo cambiare un po' argomento (basta con 'ste funzioni di copia!) e possiamo passare, per esempio a:

5) il mistero delle funzioni con vettori di pointer
Come possiamo generare e maneggiare un vettore di pointer (o meglio: pointer-to-pointers, per gli amici star-star) usando funzioni? Vediamo un esempio semplice semplice, con il solito main() per mostrare i risultati:

#include <stdio.h>
#include <stdlib.h>

#define N_ELEMS 3   // numero di elementi da allocare nel vettore

// una semplice struttura di dati
typedef struct {
    int  id;
    char name[32];
} s_data;

// prototipi locali
s_data **allocVect(s_data **dest, size_t n_elems);
void   freeVect(s_data **dest, size_t n_elems);

// funzione main
int main(int argc, char *argv[])
{
    // alloco il vettore per il test
    s_data **datalist = allocVect(datalist, N_ELEMS);

    // scorro il vettore e mostro il contenuto
    for (int i = 0; i < N_ELEMS; i++)
        printf("allocVect(): datalist[%d]: id=%d name=%s\n",
               i, datalist[i]->id, datalist[i]->name);

    // libero il vettore
    freeVect(datalist, N_ELEMS);

    return 0;
}

// allocVect - alloca un vettore di pointer
s_data **allocVect(s_data **dest, size_t n_elems)
{
    // alloco il pointer-to-pointers
    dest = malloc(n_elems * sizeof(s_data));

    // alloco i pointer
    for (int i = 0; i < n_elems; i++) {
        dest[i] = malloc(sizeof(s_data));

        // questa parte è solo un esempio per mettere dei dati da mostrare nel main()
        dest[i]->id = i;
        snprintf(dest[i]->name, sizeof(dest[i]->name), "name_%d", i);
    }

    // ritorna il pointer-to-pointers
    return dest;
}

// freeVect - libera un vettore di pointer
void freeVect(s_data **dest, size_t n_elems)
{
    // scorro il vettore e libero ogni pointer
    for (int i = 0; i < n_elems; i++)
        free(dest[i]);

    // libera il pointer-to-pointers
    free(dest);
}

Avete visto? Ho scritto due semplicissime funzioni per allocare e liberare un vettore di puntatori (star-star), e la chiave del funzionamento (ben commentata, direi) è la seguente: quando abbiamo un vettore di pointer bisogna creare prima il pointer-to-pointers base (con malloc()) e poi bisogna creare i singoli puntatori del vettore (sempre con malloc()). E quando si libera il vettore bisogna, ovviamente, seguire l'ordine inverso (prima i puntatori singoli e poi il pointer-to-pointers principale). nell'esempio appena mostrato ho aggiunto nel loop di creazione una inserzione di dati, per avere qualcosa da mostrare nel main(): compilatelo, vi assicuro che funziona...

Notare che in questo caso il meccanismo di passaggio e uso degli argomenti è quello visto negli esempi "non canonici" visti nei precedenti misteri: si passa un argomento spurio (un dest non allocato) e lo si restituisce allocato al chiamante. Semplice, no?

E dopo questo esempio credo che siamo pronti per l'ultimo mistero di questa seconda e (per il momento) ultima parte dell'articolo:

6) il mistero delle funzioni per maneggiare linked-list
Le linked-list sono uno dei grandi misteri del C, eppure sono utilissime, e sono anche molto semplici da usare! Vediamo un esempio veramente elementare:

#include <stdio.h>
#include <stdlib.h>

#define N_NODES 3   // numero di nodi nella linked list

// nodo di una linked list singola con campo dati
typedef struct snode {
    int data;
    struct snode *next;
} node_t;

// prototipi locali
void addNode(node_t **head, int data);

// funzione main
int main(int argc, char *argv[])
{
    // init lista vuota e inserisce con addNode() N_NODES nodi con data = indice loop
    node_t *head = NULL;
    for (int i = 1; i <= N_NODES; i++)
        addNode(&head, i);

    // scorre la lista e stampa i valori (compresi gli indirizzi)
    node_t *my_head = head;
    printf("my_head=%p\n", my_head);
    while (my_head) {
        printf("data=%d (my_head=%p next=%p)\n", my_head->data, my_head, my_head->next);
        my_head = my_head->next ;
    }

    return 0;
}

// addNode - alloca in testa a una lista un node con dati e puntatore al prossimo elemento
void addNode(node_t **head, int data)
{
    // alloca un nuovo node
    node_t *node = malloc(sizeof(node_t));
    node->data = data;
    node->next = *head;

    // assegna head lista al nuovo node
    *head = node;
}

Cosa dire? più elementare di così! Eppure funziona... Come si evince dagli abbondanti commenti per fare una linked-list basta creare un punto di inizio (un "head") e aggiungere nodi con una semplicissima funzione che ho chiamato (in modo veramente originale) addNode(). Il segreto sta nella struttura del "nodo", che deve sempre contenere un puntatore al nodo successivo (ma va? Sarà mica per questo che si chiamano linked-list?). Ovviamente l'esempio fornito è abbastanza limitato, e mancano le funzioni per cancellare nodi, per appendere (invece di aggiungere) nodi, oppure per gestire la lista in modo doppio (double-linked-list), ecc., ecc. Ma sulla (solida) base fornita è possibile costruire, in modo relativamente semplice, tutte le estensioni che vogliamo.

Una ultima cosa: notare che il main() mostra, a titolo di esempio, il campo data dei nodi aggiunti insieme agli indirizzi del nodo corrente e del prossimo, e questo ci aiuta a vedere in pratica come funziona il meccanismo.

Beh, direi che con i tre misteri di oggi abbiamo svelato ulteriori dettagli arcani delle funzioni C. Ne rimangono ancora molti, ma per il momento ci prenderemo una pausa, perché sento già friggere molti neuroni e non vorrei creare danni irreversibili...

Ciao e al prossimo post!

I Misteri delle Funzioni del C come funzionano alcune funzioni speciali in C - pt.1

Mr. Neville: quattro indumenti e una scala non ci portano a un cadavere.
Sig.ra Talmann: Sig. Neville, non ho parlato di un cadavere.

Nel gran film I misteri del giardino di Compton House, un disegnatore (un programmatore?) riceve l'incarico di disegnare 12 disegni (12 funzioni?) di una aristocratica casa di campagna: si scoprirà, poi, che ogni disegno contiene e rappresenta un mistero (come funziona questa funzione?). Ebbene, girando su vari siti di programmazione (tipo l'ottimo stackoverflow, per intenderci), ho notato che, a volte, anche programmatori "scafati" hanno dubbi su concetti di base (...ammettiamolo, siamo umani...). Ecco, oggi parleremo di funzioni: sono il pane quotidiano di ogni programmatore C eppure, in alcuni casi, hanno un funzionamento misterioso. Vediamone qualcuna...

...siamo qui riuniti per spiegare una funzione misteriosa...

Cominciamo con un caso semplice semplice, che possiamo chiamare così:

1) Il mistero delle funzioni con un parametro array
Quando dobbiamo passare un array a una funzione è meglio usare come argomento un array? E quando dobbiamo passare un pointer è meglio usare un argomento pointer? Beh, visto che il caso è semplice diamo subito la risposta: È la stessa cosa! Gli argomenti array di una funzione vengono (magicamente) trasformati in pointer dal compilatore: è un comportamento standard  ben documentato anche sul mitico K&R:

"Quando il nome di un vettore viene passato ad una funzione, ciò che viene passato è la posizione dell’elemento iniziale. All’interno della funzione chiamata, questo argomento è una variabile locale, quindi un nome di vettore passato come parametro è in realtà un puntatore, ovvero una variabile che contiene un indirizzo." (Il Linguaggio C - 2a.ed. - B.W.Kernighan, D.M.Ritchie)

Comunque, già che ci siamo, vediamo due piccoli esempi che ci serviranno anche più avanti. Vai con l'esempio che usa l'array!

// prototipi locali
void myfunc(char arg[]);

// funzione main
int main(int argc, char *argv[])
{
    // set variabile e chiamo myfunc()
    char string[] = "pippo";
    myfunc(string);

    return 0;
}

// funzione myfunc con array
// anche mettendo la dimensione (i.e.: char arg[100]) il codice 
// generato è identico
void myfunc(char arg[])
{
    char a = arg[3]
}

E, a seguire, l'esempio che usa il pointer!

// prototipi locali
void myfunc(char *arg);

// funzione main
int main(int argc, char *argv[])
{
    // set variabile e chiamo myfunc()
    char *string = "pippo";
    myfunc(string);

    return 0;
}

// funzione myfunc con pointer
// questa è la versione a cui viene ricondotta dal compilatore una eventuale 
// versione con array
void myfunc(char *arg)
{
    char a = arg[3];
}

Allora: le due funzioni myFunc() sono perfettamente equivalenti, o meglio: la myFunc() con l'array si trasforma in quella con il pointer (e non importa se scriviamo anche la dimensione dell'array: 10, 100, 1000, non cambia nulla!). E per quelli che sono come San Tommaso (che non ci crede se non ci mette il naso) consiglio un piccolo esperimento: compilare per ottenere l'assembly (con gcc -S, per esempio) e verificare che il codice delle funzioni è identico, e che le uniche differenze sono nel corpo del main()... ma non dovrebbe essere praticamente identico anche quest'ultimo? Forse che "char *string = "pippo";" sviluppa codice assembly molto diverso da quello di "char string[] = "pippo";"? Ebbene si, quindi siamo pronti per analizzare un altro mistero:

2) Il mistero delle funzioni che restituiscono una stringa letterale
Sicuramente saprete tutti che una funzione non deve mai restituire l'indirizzo di una variabile locale (vabbè: una variabile automatica allocata nello stack della funzione), perché quando la funzione "esce" la variabile va out-of-scope e l'indirizzo passato al chiamante non è più valido. E allora come si fa una funzione che ritorna una stringa? Vediamo un esempio:

#include <stdio.h>

// prototipi locali
char *myfunc1(void);
char *myfunc2(void);

// funzione main
int main(int argc, char *argv[])
{
    // mostro il risultato delle funzioni
    printf("myfunc1(): %s\n", myfunc1());
    printf("myfunc2(): %s\n", myfunc2());

    return 0;
}

// funzione myfunc1 - questa funziona
char *myfunc1(void)
{
    char *string = "pippo";
    return string;  // Ok: string è (implicitamente) una variabile statica
}

// funzione myfunc2 - questa non funziona
char *myfunc2(void)
{
    char string[] = "pluto";
    return string;  // NOk: string è una variabile locale (con Warning in compilazione!)

} 

a prima vista anche myFunc1() sembrerebbe un esempio da manuale di come non fare una buona funzione! Eppure funziona (leggere i commenti), e non per caso. Il fatto è che la stringa string in myFunc1() non è una variabile locale, infatti viene (implicitamente) allocata, direttamente dal compilatore, in una zona Read Only della memoria e quindi è, a tutti gli effetti, una variabile statica. Per cui l'esempio qui sopra funziona ed è la maniera migliore di fare una funzione che ritorna una stringa. Ed attenzione: se invece usiamo un array, come è il caso della myFunc2() non funziona: questo si che viene trattato come variabile locale (ecco perché i due main() del mistero numero 1 erano diversi!). Notare, infine, che myFunc1() e la sua variabile string interna dovrebbero essere dichiarate const, visto che la stringa "pippo" ritornata non è modificabile, quindi usando il qualificatore const permettiamo al compilatore di segnalarci eventuali operazioni non permesse (provate a modificare il contenuto di una inmutable string, vedrete che bell'effetto!). Ho scritto "dovrebbero essere dichiarate const" in corsivo perché non è obbligatorio: è solo consigliabile farlo, ma non è che rende il codice a prova di bomba...

E dopo aver visto i due casi precedenti siamo ben preparati e pronti a vedere il terzo mistero:

3) Il mistero delle funzioni che restituiscono un char pointer
Nella libc ci sono un bel po' di funzioni che restituiscono un char* (per gli amici "char star"), come ad esempio quelle delle famiglia string. Come sono fatte? Ci sono alternative valide alla struttura "classica"? Vediamo un esempio con una implementazione minimale delle strcpy() e strncpy(), senza controlli, senza ottimizzazioni, senza tutto, ma per un esempio è più che sufficiente. Vediamo il codice, che include anche un piccolo e semplice main() di test:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// prototipi locali
char *myStrcpy(char *dest, const char *src);
char *myStrncpy(char *dest, const char *src, size_t len);
char *myStrncpyMalloc(char *dest, const char *src, size_t len);

// funzione main
int main(int argc, char *argv[])
{
    // eseguo myStrcpy() e mostro il risultato
    char *src1 = "pippo";
    char dest1[32];
    printf("myStrcpy(): dest = %s\n", myStrcpy(dest1, src1));

    // eseguo myStrncpy() e mostro il risultato
    char *src2 = "paperino";
    char dest2[32];
    printf("myStrncpy(): dest = %s\n", myStrncpy(dest2, src2, strlen(src2)));

    // eseguo myStrncpyMalloc() e mostro il risultato
    char *src3 = "paperone";
    char *dest3 = myStrncpyMalloc(dest3, src3, strlen(src3));
    printf("myStrncpyMalloc(): dest = %s\n", dest3);
    free(dest3);    // ricordarsi di questa free()

    return 0;
}

// myStrcpy - versione semplificata della strcpy() della libc
char *myStrcpy(char *dest, const char *src)
{
    // salvo localmente dest
    char *my_dest = dest;

    // loop per copiare src sulla copia locale di dest
    while (*src)
       *my_dest++ = *src++;

    // ritorno il dest salvato
    return dest;
}

// myStrncpy - versione semplificata della strncpy() della libc
char *myStrncpy(char *dest, const char *src, size_t len)
{
    // salvo localmente dest
    char *my_dest = dest;

    // loop per copiare src sulla copia locale di dest (copio solo <len> caratteri)
    while (*src && len--)
       *my_dest++ = *src++;

    // aggiungo il terminatore di stringa
    *my_dest = 0;

    // ritorno il dest salvato
    return dest;
}

// myStrncpy - versione con malloc interna di myStrncpy()
char *myStrncpyMalloc(char *dest, const char *src, size_t len)
{
    // alloco dest (N.B.: la free() la deve fare il chiamante della myMemcpyMalloc())
    dest = malloc(len + 1); // il +1 è per il terminatore di stringa

    // salvo localmente dest
    char *my_dest = dest;

    // loop per copiare src sulla copia locale di dest (copio solo <len> caratteri)
    while (*src && len--)
       *my_dest++ = *src++;

    // aggiungo il terminatore di stringa
    *my_dest = 0;

    // ritorno il dest salvato
    return dest;
}

Avete notato la semplicità del meccanismo? Nella myStrcpy() Si salva localmente il destino <dest> e, in un loop, si copia "byte-a-byte" <src> sulla copia locale di <dest> (fermandosi quando si raggiunge il terminatore di stringa di <src>). Infine, si restituisce il pointer originale <dest> e non la sua copia. E perché l'originale? perchè l'operazione viene eseguita incrementando i pointer di <src> e <dest>, quindi dobbiamo restituire il pointer originale e non quello incrementato nel loop. E la myStrncpy()? Come si nota è formalmente identica alla myStrcpy(), con la unica differenza che usa un argomento addizionale <len> per copiare solo <len> caratteri (invece di arrivare fino al terminatore di stringa). Il terminatore viene aggiunto poi internamente alla funzione, proprio perché è possibile che la copia non arrivi fino alla fine della stringa originale.

E visto che volevo strafare (si, strafacciamo: Punto! Due punti!... ma sì, fai vedere che abbondiamo... Abbondandis in abbondandum...) ho creato e aggiunto anche un altra funzione, la myStrncpyMalloc(), che è una versione poco canonica della strncpy() che si occupa anche di allocare internamente (con malloc()) il destino della copia: è molto comoda, visto che possiamo passare direttamente un pointer non allocato nell'argomento <dest> (vedi il main() qui sopra), ma poi dobbiamo ricordarci di liberarlo! (vedi di nuovo il main() qua sopra). E se ci dimentichiamo di fare la free() sono dolori...

Beh, direi che con i tre misteri di oggi abbiamo già svelato molti dettagli arcani di alcune funzioni C. Ne rimangono ancora molti, e avremo tempo di parlarne più avanti nella seconda parte del post dove, sicuramente, troveremo un altro vecchio amico: void* (per gli amici "void star")... e mi raccomando: non trattenete il respiro nell'attesa...

Ciao e al prossimo post!

Lo chiamavano Jeeg OpenSSL come scrivere TCP Server e Client con OpenSSL in C - pt.2

Alessia: N'è pe' critica', eh! Però, amore mio, quando te trasformi te devi cambià 'ste scarpe. Cioè, 'n supereroe co' e scarpe de camoscio 'n s'è mai visto, dai! L'hai mai visto te? 'N s'è mai visto...

Ci risiamo: anche per questa seconda puntata di Lo chiamavano Jeeg Robot (oops: Lo chiamavano Jeeg OpenSSL) abbiamo due notizie, una buona e una cattiva. La buona è che per un sistema Client/Server elementare, come quello presentato nella prima parte (che avete già letto, spero...), si possono usare le funzioni OpenSSL "così come sono" (ricordate? Era un esempio "interattivo" a bassissimo volume di dati scambiati a bassissima velocità). La cattiva notizia è che nel mondo reale, quello dove un sistema Client/Server può scambiare molti dati e ad alta frequenza, le funzioni OpenSSL bisogna usarle con gli opportuni accorgimenti, se no non funziona niente. E poi mi chiedo: ma si può scrivere del buon Software con le scarpe di camoscio?

...'n openSSL co' e scarpe de camoscio 'n s'è mai visto...

Allora, come vi avevo anticipato, ho scritto una piccola libreria di smart-wrapper per alcune delle funzioni OpenSSL. La libreria si chiama libmyssl (nome originalissimo) ed è composta da due file, myssl.c e myssl.h. Vediamo subito myssl.h così ci togliamo il pensiero:

#ifndef MYSSL_H
#define MYSSL_H

#include <openssl/ssl.h>
#include <stdbool.h>

// nomi file certificati
#define RSA_SERVER_CERT     "client.pem"
#define RSA_SERVER_KEY      "key.pem"
#define RSA_CLIENT_CA_CERT  "ca.pem"

// tipi per sslCreateCtx()
#define SSL_SERVER  0
#define SSL_CLIENT  1

// timeout e iterazioni per funzioni interne openSSL: sslRead()/sslwrite()/sslFunc
#define SSL_RWTOUT  100000  // timeout per funzioni interne (e.g.: 100000 us = 100 ms)
#define SSL_RWITER  20      // numero di iterazioni in RWSSL_TOUT
                            // (e.g.: tot.timeout = 100 ms * 20 = 2 sec
// altre define
#define BACKLOG     10      // numero connessioni per coda listen(): valore ragionevole
                            // per multi-connect (e non fa danni in single-connect)
#define MYBUFSIZE   1024    // size buffer per send/recv

// prototipi globali
SSL_CTX* sslCreateCtx(int type, int *error);
int      sslWrite(SSL *ssl, const void *buf, int num);
int      sslRead(SSL *ssl, void *buf, int num);
int      sslFunc(int (*pfunc)(SSL*), SSL *ssl);
void     sslClose(SSL *ssl, int sock, SSL_CTX *ctx, bool do_shutdown);

#endif /* MYSSL_H */

Vedete? Sono quattro cose ben commentate e che rivedremo nella descrizione di myssl.c, per cui non credo sia necessario perderci in dettagli: notare solo l'uso degli include guard per il nostro header file: questa è una libreria che possiamo includere da più file dello stesso progetto, quindi bisogna premunirsi contro eventuali (erronee) inclusioni multiple. Notare poi la lista delle funzioni contenute nella libreria che non può mancare in un header file come questo: le funzioni sono quelle già viste nel codice della parte 1 del post. Ed ora bando alle ciance: passiamo all'implementazione vera e propria, vai col codice!

#include "myssl.h"
#include <unistd.h>

// prototipi locali
static bool sslRecovery(SSL *ssl, int sslresult);
static int  sslSelectRd(SSL *ssl);
static int  sslSelectWr(SSL *ssl);

////////////////////////////////////////////////////////////////////////////////
// funzioni GLOBALI
////////////////////////////////////////////////////////////////////////////////

// sslCreateCtx - crea un openSSL context
SSL_CTX* sslCreateCtx(
    int type,               // tipo di contesto: SSL_SERVER/SSL_CLIENT
    int *error)             // flag di errore
{
    // load algoritmi di encryption+hashing per SSL
    SSL_library_init();

    // load string di errore per SSL+CRYPTO APIs
    SSL_load_error_strings();

    // create una struttura SSL_METHOD (usando uno dei protocolli SSL/TLS disponibili)
    const SSL_METHOD *meth = SSLv23_method();

    // crea una struttura SSL_CTX
    *error = 0;     // senza errore per default
    SSL_CTX *my_ctx;
    if ((my_ctx = SSL_CTX_new(meth)) == NULL) {
        // errore: unset flag di errore e ritorna contesto (==NULL)
        *error = 0;
        return my_ctx;
    }

    // test modo server/client
    if (type == SSL_SERVER) {
        // SERVER: load del certificato server nella struttura SSL_CTX
        if (SSL_CTX_use_certificate_file(my_ctx, RSA_SERVER_CERT, SSL_FILETYPE_PEM) != 1) {
            // errore: set flag di errore e ritorna contesto
            *error = -1;
            return my_ctx;
        }

        // load del private-key corrispondente al certificato server
        if (SSL_CTX_use_PrivateKey_file(my_ctx, RSA_SERVER_KEY, SSL_FILETYPE_PEM) != 1) {
            // errore: set flag di errore e ritorna contesto
            *error = -1;
            return my_ctx;
        }

        // check della coerenza tra certificato server e private-key
        if (SSL_CTX_check_private_key(my_ctx) != 1) {
            // errore: set flag di errore e ritorna contesto
            *error = -1;
            return my_ctx;
        }
    }
    else {
        // CLIENT: load del certificato RSA-CA nella struttura SSL_CTX
        // (serve a verificare il certificato server sul client)
        if (SSL_CTX_load_verify_locations(my_ctx, RSA_CLIENT_CA_CERT, NULL) != 1) {
            // errore: set flag di errore e ritorna contesto
            *error = -1;
            return my_ctx;
        }

        // set flag in SSL_CTX per richiedere la verifica del certificato server
        SSL_CTX_set_verify(my_ctx, SSL_VERIFY_PEER, NULL);
        SSL_CTX_set_verify_depth(my_ctx, 1);
    }

    // unset flag di errore e ritorna un contesto valido
    *error = 0;
    return my_ctx;
}

// sslWrite - scrive dati in modo smart in una connessione SSL/TLS
int sslWrite(
    SSL        *ssl,        // struttura SSL per openSSL
    const void *buf,        // buffer dei dati da scrivere
    int        num)         // numero dei dati da scrivere
{
    int sent;

    // loop di scrittura
    int count = 0;
    for (;;) {
        // test del loop counter (tot.timeout = SSL_RWTOUT * SSL_RWITER)
        if (++count > SSL_RWITER) {
            // il timeout totale è scaduto: interrompo il loop
            // (e.g.: tot.timeout = 100 ms * 20 = 2 sec)
            break;
        }

        // scrive dati
        sent = SSL_write(ssl, buf, num);
        if (sent > 0) {
            // scrittura Ok: interrompo il loop
            break;
        }
        else {
            // scrittura NOK (risultato <= 0): start procedura di recovery
            if (sslRecovery(ssl, sent))
                continue; // ci sono ancora dati da leggere/scrivere: continuo nel loop

            // interrompo il loop
            break;
        }
    }

    // ritorna il numero di byte scritti o errore
    return sent;
}

// sslRead - legge dati in modo smart in una connessione SSL/TLS
int sslRead(
    SSL  *ssl,              // struttura SSL per openSSL
    void *buf,              // buffer dei dati da leggere
    int  num)               // numero dei dati da leggere
{
    int rcvd;

    // loop di lettura
    int count = 0;
    for (;;) {
        // test del loop counter (tot.timeout = SSL_RWTOUT * SSL_RWITER)
        if (++count > SSL_RWITER) {
            // il timeout totale è scaduto: interrompo il loop
            // (e.g.: tot.timeout = 100 ms * 20 = 2 sec)
            break;
        }

        // legge dati
        rcvd = SSL_read(ssl, buf, num);
        if (rcvd > 0) {
            // lettura Ok: interrompo il loop
            break;
        }
        else {
            // lettura NOK (risultato <= 0): start procedura di recovery
            if (sslRecovery(ssl, rcvd))
                continue; // ci sono ancora dati da leggere/scrivere: continuo nel loop

            // interrompo il loop
            break;
        }
    }

    // ritorna il numero di byte lett o errore
    return rcvd;
}

// sslFunc - wrapper smart per sslConnect()/sslAccept()/sslShutdown()
int sslFunc(
    int  (*pfunc)(SSL*),    // pointer alla funzione da eseguire
    SSL* ssl)               // struttura SSL per openSSL
{
    int result;

    // loop di esecuzione della funzione
    int count = 0;
    for (;;) {
        // test del loop counter (tot.timeout = SSL_RWTOUT * SSL_RWITER)
        if (++count > SSL_RWITER) {
            // il timeout totale è scaduto: interrompo il loop
            // (e.g.: tot.timeout = 100 ms * 20 = 2 sec)
            break;
        }

        // esegue funzione
        result = pfunc(ssl);
        if (result > 0) {
            // funzione Ok: interrompo il loop
            break;
        }
        else {
            // funzione NOK (risultato <= 0): start procedura di recovery
            if (sslRecovery(ssl, result))
                continue; // ci sono ancora dati da leggere/scrivere: continuo nel loop

            // interrompo il loop
            break;
        }
    }

    // ritorna il risultato della funzione o errore
    return result;
}

// sslClose - chiude una sessione ssl
void sslClose(
    SSL     *ssl,           // struttura SSL per openSSL
    int     sock,           // socket aperto per la sessione
    SSL_CTX *ctx,           // ssl context aperto per la sessione
    bool    do_shutdown)    // flag per eventuale esecuzione di SSL_shutdown()
{
    // libera ssl (ed esegue shutdown) se allocato
    if (ssl) {
        // eventualmente esegue shutdown
        if (do_shutdown)
            sslFunc(SSL_shutdown, ssl);

        // libera ssl
        SSL_free(ssl);
    }

    // libera socket
    close(sock);

    // libera ctx se allocato
    if (ctx)
        SSL_CTX_free(ctx);
}

////////////////////////////////////////////////////////////////////////////////
// funzioni LOCALI
////////////////////////////////////////////////////////////////////////////////

// sslRecovery - esegue una procedura di recovery su una operazione ssl fallita
static bool sslRecovery(
    SSL *ssl,               // struttura SSL per openSSL
    int sslresult)          // risultato ssl da recuperare
{
    bool result = false;    // risultato di default

    // test errore ssl
    switch (SSL_get_error(ssl, sslresult)) {
    case SSL_ERROR_WANT_READ:
        // dati non ancora disponibili: bisogna aspettare (con select())
        if (sslSelectRd(ssl) > 0)
            result = true;  // ci sono ancora dati da leggere

        break;

    case SSL_ERROR_WANT_WRITE:
        // dati non ancora scrivibili: bisogna aspettare (con select())
        if (sslSelectWr(ssl) > 0)
            result = true;  // posso ancora scrivere dati

        break;

    case SSL_ERROR_ZERO_RETURN:
        // il peer si è disconnesso: non bisogna aspettare
        break;

    default:
        break;
    }

    // ritorna il risultato del recovery
    return result;
}

// sslSelectRd - esegue una select() in lettura su un openssl file descriptor
static int sslSelectRd(
    SSL *ssl)               // struttura SSL per openSSL
{
    // ottiene il socket file descriptor associato al socket ssl
    int sock = SSL_get_rfd(ssl);

    // prepara il file descriptor set associato al socket fd <sock>
    fd_set fds;
    FD_ZERO(&fds);
    FD_SET(sock, &fds);

    // set timeout
    struct timeval timeout;
    timeout.tv_sec  = 0;
    timeout.tv_usec = SSL_RWTOUT;   // timeout

    // ritorna il risultato della select() sul file descriptor set
    return select(sock + 1, &fds, NULL, NULL, &timeout);
}

// sslSelectWr - esegue una select() in scrittura su un openssl file descriptor
static int sslSelectWr(
    SSL *ssl)               // struttura SSL per openSSL
{
    // ottiene il socket file descriptor associato al socket ssl
    int sock = SSL_get_wfd(ssl);

    // prepara il file descriptor set associato al socket fd <sock>
    fd_set fds;
    FD_ZERO(&fds);
    FD_SET(sock, &fds);

    // set timeout
    struct timeval timeout;
    timeout.tv_sec  = 0;
    timeout.tv_usec = SSL_RWTOUT;   // timeout

    // ritorna il risultato della select() sul file descriptor set
    return select(sock + 1, NULL, &fds, NULL, &timeout);
}

Ok, sono cinque funzioni, tutte ben commentate (quindi non ci sarà bisogno di descriverle linea per linea) e possiamo dividerle in due gruppi: due facili-facili che servono, praticamente, solo per aprire e chiudere l'attività: sslCreateCtx() e sslClose(), e altre tre un po' più complicate che sono gli smart-wrapper anticipati sopra: sslWrite(), sslRead() e sslFunc().

Cominciamo con sslCreateCtx(): openSSL lavora appoggiandosi su un contesto di tipo SSL_CTX* che serve come base di lavoro per tutte le operazioni della libreria. sslCreateCtx() crea questo contesto con due personalità distinte: Client e Server, quindi, come avrete notato, nel codice ci sono alcune attività comuni, e alcune attività che dipendono dal parametro type (che vale SSL_SERVER o SSL_CLIENT). Leggetevi bene i commenti per seguire il flusso che è semplice e chiarissimo. Notare solo che, visto che OpenSSL è un protocollo che usa certificati di sicurezza, sul lato Client avremo bisogno di un file-certificato di tipo CA, mentre sul lato Server avremo i due file-certificati di tipo KEY e CERT corrispondenti al CA del Client. L'argomento di questo post esula i dettagli di come funzionano e come si generano questi certificati (bisognerebbe fare un lungo post solo sull'argomento!), ma in rete c'è molta documentazione al riguardo ed è facilissimo trovare guide per poter generare senza problemi i tre file necessari per il funzionamento. sslCreateCtx() ritorna, se tutto va bene, un contesto valido (my_ctx != NULL) e senza errori (error == 0). Potrebbe però anche ritornare un contesto non valido (my_ctx == NULL) o un errore (error == -1): il chiamante deve processare tutte queste possibilità (esattamente come proposto negli esempi della parte 1 del post).

Passiamo all'altra funzione facile-facile: sslClose() serve, evidentemente, a chiudere in maniera ordinata tutto ciò che si è aperto per far funzionare il sistema Client/Server, e quindi: il contesto SSL_CTX* creato con SSL_CTX_new(), la struttura SSL* creata con SSL_new() e il socket creato con socket().

Come ben sapete "quando il gioco si fa duro i duri cominciano a giocare", quindi è venuto il momento degli smart-wrapper! Sono: sslWrite(), sslRead() e sslFunc(). I primi due servono, evidentemente, a gestire le operazioni di write e read (tramite le funzioni OpenSSL SSL_write() e SSL_read()), mentre il terzo è più generico e serve a gestire le operazioni di shutdown, accept e connect (tramite le funzioni OpenSSL SSL_shutdown(), SSL_accept() e SSL_connect()). Ovviamente non ho usato sslFunc() anche per read e write perché gli argomenti delle funzioni erano decisamente incompatibili.

Visto che i nostri smart-wrapper sono strutturalmente identici ne descriverò solo uno, ma prima di farlo dobbiamo fare mente locale e capire perché abbiamo bisogno degli smart-wrapper. Il fatto è che il funzionamento di openSSL è più complesso di quello che sembra: in una normale connessione socket quando spedisci dei dati lo fai e ti fermi li (e se sei bravo testi il codice di errore della send()). Eventuali risposte sono da gestire a un livello più alto: decido io (e non il protocollo) se un messaggio ha bisogno di una risposta. In OpenSSL non è così: fondamentalmente il problema è che ogni read implica una write implicita e viceversa. Cioè, c'è sempre una fase di negoziazione della comunicazione e, ad esempio, non si può considerare conclusa una operazione di send fatta con SSL_write() fino a quando il sistema non ci comunica che tutte le operazioni di read/write sono terminate.

Ma vediamo subito come funziona sslFunc() e tutto risulterà, magicamente, più chiaro: sslFunc() esegue la funzione che le passiamo (via function-pointer con l'argomento pfunc)). La funzione viene eseguita in loop (e qui cominciano le stranezze...), quindi viene eseguita più volte, fino a quando l'operazione è veramente terminata. Se tutto va bene (ma proprio bene!) la funzione si esegue nel loop una sola volta, e si esce con Ok. E se va male... si chiama sslRecovery() che è una funzione locale della libreria libmyssl: la sslRecovery() analizza il codice di errore che le viene passato e che può valere:

1. SSL_ERROR_WANT_READ: dati non ancora disponibili: bisogna aspettare
2. SSL_ERROR_WANT_WRITE: dati non ancora scrivibili: bisogna aspettare 
3. SSL_ERROR_ZERO_RETURN: il peer si è disconnesso: non bisogna aspettare

Il caso 3 è, evidentemente, un errore irrecuperabile da comunicare al chiamante della sslRecovery(), mentre i casi 1 e 2 ci dicono solo che "bisogna aspettare" perché ci sono ancora attività di read/write da completare. E come aspettiamo? Per farlo abbiamo a disposizione una coppia di funzioni locali della libreria, e cioe sslSelectRd() e sslSelectWr()), che fanno uso della system call select() per aspettare sullo stream di read o write pertinente. La select() è una system call utile e interessantissima, su cui si potrebbe scrivere un intero post: nell'attesa (di un eventuale post) vi invito a leggere la pagina del manuale e i commenti del codice: si vede chiaramente che viene usata solo per aspettare (con il timeout che abbiamo fissato con la define SSL_RWTOUT), sperando che durante l'attesa l'operazione di I/O vada a buon fine.  

Un ultimo accenno sul loop contenuto nella sslFunc(): è infinito (uh, che rischio!) ma con il trucco: esce con un timeout nel caso qualcosa vada completamente storto (mai fidarsi dei loop infiniti...). Il timeout è ben descritto sia in myssl.h che in myssl.c, e con i valori dell'esempio dopo 2 secondi il loop termina forzatamente (con errore, ovviamente).

That's all folks!

Uff, che fatica, credo che per (almeno per il momento) l'argomento OpenSSL lo possiamo considerare chiuso. Certo che abbiamo visto un Client e un Server che invece di chiamare direttamente le funzioni OpenSSL chiamano funzioni di una libreria scritta ad-hoc, e che a loro volta chiamano funzioni locali della libreria... ma la vita del programmatore non potrebbe essere più semplice? Vabbè io in realtà così mi diverto molto... A voi sembra strano? Ma mai strano come quelli che scrivono Software con le scarpe di camoscio...

Ciao e al prossimo post!